Did you know that the PMI-ACP exam is changing on July 15, 2015?

Did you know that the PMI-ACP exam is changing on July 15, 2015?

In December 2014, a new PMI-ACP® Exam Content Outline was published which goes into effect in July 2015. The new content of the exam was determined by PMI through both a study and a survey. The following is a description of their approach:

“Recently, a Role Delineation Study (RDS) involving over 1,000 agilists from 60 countries produced an updated description of the agile practitioner. The RDS plays a central role in constructing a valid exam for the PMI-ACP.

A large-scale survey of certified PMI-ACP holders and non-certified agile practitioners validated revisions to domains, tasks, knowledge and skills, as well as tools and techniques.”

Given that I am an active trainer on PMI-ACP content and also offer practice exams and a self-study course, I performed a detailed gap analysis against the original 2011 exam content outline and the current version. If you are interested, you can download this detailed gap analysis here.

In summary, the changes were as follows:

  • 1 new Domain: Agile Principles and Mindset
  • 14 new or substantially reworded Tasks
  • 30 new topics under Tools and Techniques
  • 3 new topics under Knowledge and Skills (12 were removed)
  • 4 reference books were added and 4 were removed

I think this is a great change. The first version, which I took and passed not long after it was launched in 2011, was comprehensive but missed some key contemporary topics Agile such as Kanban. For example, in this version of the Exam Content Outline, PMI has added two new references on Kanban alone:

Kanban In Action: Marcus Hammarberg, Joakim Sunden

Kanban: Successful Evolutionary Change for your Technology Business, David J. Anderson

I have read all four of the references and I agree that they are excellent additions to reading list. You can find the complete list of old and new references here.

PMI is piloting this exam starting on July 15, 2015 and offering discounts to those people who take it prior to August 15, 2015. The dates from PMI’s website are as follows:

July 15, 2015 Pilot period begins.
July 15 – August 16, 2015 Receive a 20% rebate on your exam fee.
July 15 – October 14, 2015 The new exam will be administered, with scores delivered on or before October 22.
October 15, 2015 Pilot period ends, receive your score immediately after testing.

For those people who are truly interested in effectively understanding and implementing Agile, this is a great certification. I understand that certification doesn’t necessarily make you effective, but by preparing for this exam you have to learn All About Agile*. Typically, most people only take Scrum Master training which exposes them to Scrum and the Agile Manifesto.

As you may or may not know, many organizations are struggling with their Scrum implementations because they think that is the only way to be Agile, without realizing that there are many different approaches, tools and techniques beyond Scrum which could help them to be successful.

By preparing for this exam, you will be exposed to so much more than Scrum. I won’t go into this more here, since I cover this topic in a recent blog at length but suffice to say, you need to select and Agile project management approach that is right for your organization.

* All About Agile is also the name of my PMI-ACP preparation course. I recently spent hundreds of hours updating my training content and incorporating those changes into my practice exams and self-study course. If you are interested in taking my course or reviewing my free intro module with sample questions, you can learn more here: http://bit.ly/ACPSelfStudy.

register

About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP

Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.

Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.

Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst. He is also a Certified Project Management Professional, Professional Scrum Master I, PMI Agile Certified Practitioner and Certified Scrum Professional.

Dan Tousignant, President

Cape Project Management, Inc.

https://capeprojectmanagement.learnupon.com/store/

http://AgileProjectManagementTraining.com

https://twitter.com/scrumdan

Contact: Dan@CapeProjectManagement.com

BE AGILE.™

Do you know where you are going with your Agile implementation?

Do you know where you are going with your Agile implementation?

Agile_ImplementationWhat every executive needs to know!

Over the past decade, I've been involved in more than 20 Agile projects. Whether as a team member, Product Owner, Scrum Master, or Coach, I've had the opportunity to play a role in many successful projects. These days, however, I’m being brought in (more and more often) to prevent Agile failures. It isn't so much that the projects themselves are failing, but that organizational impediments are preventing success. Why? Version One’s most recent annual State of Agile Survey found that an “inability to change organizational culture” and “general resistance to change” are the most common reasons Agile projects fail.
.
I believe the bulk of these failures can be traced back to the initial implementation phases. For instance, were these organizations truly aware of what they were getting into? And did they realize the types of change that Agile requires? In my Scrum Master trainings, I emphasize the need for organizations to truly understand and embrace the change they are about to embark upon. We discuss what type of organizational change is needed for a successful Agile implementation. The three types of organizational change we look at include:
.
Developmental
[list type="disc"]

  • Improvements on processes, methods, or performance standards
  • Done in order to stay competitive
  • Causes little stress to employees

[/list]
Transitional
[list type="disc"]

  • More intrusive because it introduces something completely new
  • Typically a planned change such as a reorganization, merger, acquisition, or implementation of a new technology
  • May cause instability and insecurity

[/list]
Transformational
[list type="disc"]

  • This leads to an organization that is very different to the organization that existed prior to the change
  • Since the change is radical, the organization and its employees need to drastically change their views, strategies, and assumptions
  • Such change can alter an organization’s culture, ethos, and systems

[/list]
Most assume that Agile is a developmental change. They see it as a process improvement and treat it as such. I would argue, however, that Agile implementation is actually closer to transformational change. Since most companies don't anticipate this transformation, care isn't taken to manage the impact of the change and the outcome is often failure. Those organizations that do see Agile as transformational are better prepared for the work needed to achieve long-term success.
.
What does it take to have a successful Agile implementation?
.
At the highest level, organizations need to outline their Agile goals and define expectations:
.

1. Is speed to market the main issue? Does the company need to deliver products more frequently?
2. Is the organization inefficient? Does it need to be “leaner” and more efficient with existing resources?
3. Is quality the issue? Does the company need to improve customer satisfaction with the software it delivers?
4. Is the organization new, or is it one that’s trying to reinvent itself and have a more empowered culture?

.
It’s critical to answer these questions before embarking on an Agile implementation.
.
With these answers, the choices become simple. If, for instance, your organization can answer YES to all four questions above, and if you're willing to do what it takes to implement the Agile approach verbatim, then you should consider implementing Scrum and XP (Extreme Programming). These are transformational approaches which focus on team empowerment and cross functional roles. They therefore require re-organization and a dramatic shift in management and leadership style.
.
I recommend using many XP practices when implementing Scrum. At an Agile New England meeting I attended a few months ago, Ken Schwaber, co-author of the Scrum Guide, stated that the merger of Scrum and XP into a single approach was originally intended. The reason for this is that Scrum doesn't dictate any specific engineering practices. XP addresses key development practices such as pair-programming and continuous integration. Its focus is on high-quality code. Technical Debt is minimized when you follow strict engineering practices. Many of the other Agile approaches make major assumptions about engineering practices already being in place. This is one of the major flaws of many current Agile implementations. If you don’t have a solid set of engineering practices and tools in place beforehand, your implementation will only have a short window of success.
.
On the other hand, if you answered NO to question number four, you should consider a more prescriptive Agile implementation. Approaches like Kanban, Scaled Agile Framework (SAFe), and Disciplined Agile Delivery (DAD) are more conservative and provide a clearer set of requirements and processes that need to be in place for the organization to be successful. I suggest that Kanban can be presented as a developmental change whereas I still consider SAFe and DAD to be transitional changes because they often require a reorganization to align with the approaches. Though I'm thoroughly familiar with Kanban, I only have passing knowledge of enterprise frameworks such as DAD and SAFe. At the enterprise level, my experience is with organizations that create their own Agile/Hybrid methodology, adopting Scrum terms but keeping many of their existing roles and processes in place. This generally creates confusion for the team members who get “certified” in Scrum but aren't actually allowed to implement Scrum as it was intended.
.
Here’s a matrix to help you choose your approach:
[table]

Goal

Scrum/XP

Kanban

SAFe/DAD

Improve project success
Be more efficient with resources
Increase IT quality
Have a more empowered culture

[/table]
.
If you've read my other blog posts, you know that I’m totally onboard when it comes to adopting a full Agile implementation of Scrum and XP—even though it’s EXTREMELY difficult. The key thing to realize when implementing Agile’s most popular approaches (Scrum, XP, DAD, SAFe, etc.) is that you must embrace the entire approach. If you don’t, you’ll quickly become susceptible to confusion and implementation “fatigue” from team members and stakeholders. The implementation will become a struggle and it will probably fail. In Scott Ambler’s 2013 IT project survey, he finds that 64% of Agile projects are successful while only 49% of traditionally run projects manage to achieve the feat. To me, this isn't an overwhelming improvement given the amount of effort required to implement Agile. It’s hard to decipher whether or not these Agile implementations were well-executed. We only really know that organizations which call themselves Agile are still struggling with 36% of their projects.
.
Summary:
.
If you're not willing to embrace cultural change, DON’T DO SCRUM OR XP. Go with Kanban, SAFe, DAD, or an internally developed hybrid instead.

If you don't have engineering best practices and support tools, such as automated regression testing and continuous integration, then YOU'RE NOT READY FOR AGILE. Step back and institute these processes first before building a new project management approach on top of a flawed foundation.

Interested in learning more about my approach to selecting a project management approach? Check out my online training Implementing Kanban for Project Management in my Agile Training store: http://buyagile.com/Kanban1
.
References:

S. Ackerman (1997) Development, Transition or Transformation: The Question of Change in Organizations

http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf

http://ambysoft.com/surveys/success2013.html
About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP

Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.

Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.

Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the owner of Cape Project Management, Inc.

Dan Tousignant, President
Cape Project Management, Inc.
Contact: Dan@CapeProjectManagement.com

BE AGILE.™

Are you implementing Scrum but realize you are better suited for Kanban?

Are you implementing Scrum but realize you are better suited for Kanban?

I have found that very few organizations are starting out with Kanban as their first choice for their Agile implementation. Almost every organization that I have been exposed to through training and coaching began their Agile implementation with Scrum. Unfortunately, many companies have significant organizational impediments to being a true Scrum shop.
.
Before I go any further, I want to say that I am a Scrum believer. If there is a way to implement “pure” Scrum, I believe you will have the most productive and happy development teams. That being said, I have found that many organizations trying to implement Scrum have significant "Scrum-buts"and their implementations would be better served by stepping back and considering a simple Kanban approach.
.
There are many different approaches to Kanban for software development, and some are even proprietary. Since everyone else is attempting to trademark their own Agile approach, from this day forward, I am trademarking, “Simple Kanban™.” Just kidding… Anyway, the benefit of Simple Kanban is that it assumes you already understand Scrum and User Stories and can apply what you have learned in Scrum to Kanban. When I train on Kanban, I train one day of Scrum and User Stories and one day of how to apply those practices to a Kanban approach.
.
I can’t say that I am an expert in Kanban for software development, but early in my career, I did have some great exposure to Kanban in manufacturing. In college, I majored in Industrial Engineering, and my first “real” job was working as a sales engineer for an environmental controls manufacturer. They used the Kanban pull system for inventory control and as part of my onboarding training  I spent three weeks on the shop floor. It was an experience that left a deep impression on me.
.
While I worked there, they won the Shingo Prize for world-class manufacturing and excellence in productivity and process improvement; quality enhancement; and customer satisfaction. This award is considered one of the “Triple Crown” industrial excellence awards, along with the Baldrige National Quality Award and the Deming Prize.
.
Kanban was originally a lean manufacturing approach, and it was developed in alignment with these 5 lean principles:
.

[list type="triangle"]

  • Specify what creates value from the customer's perspective
  • Identify all the steps along the process chain
  • Make those processes flow
  • Make only what is pulled by the customer
  • Strive for perfection by continually removing wastes

[/list]

.
These lean principles which I saw applied to manufacturing always stayed with me as my career shifted to software development project management. I was never a thought-leader advancing my ideas beyond the needs of my immediate project, but I was able to be “agile” before I even heard the term. I was applying both lean principles and common sense to keep the development teams productive and my customers happy.
.
Now that I am an Agile Coach, I have formalized my common sense approach so the process is repeatable and so I can train Agile teams. Here is how I implement Simple Kanban:
.

Keep existing functional teams: Most organizations are struggling with eliminating roles, especially QA. One major reason that this won’t change is because separation of duties is required for many IT shops.[list type="disc"]

 

  • Business Analysts perform role of Product Owner and write User Stories. They prioritize these Stories in the Product Backlog for the development team which becomes the work queue for the team to pull from. Ultimately, given the lightweight nature of User Stories, there will be fewer Analysts needed.
  • Software engineers perform high-level design, and identify the development tasks. For complex systems, it may require that an architect or senior software engineer is on the team for this activity.
  • Software engineers continue to develop, write unit tests, and advance Agile engineering practices such as continuous integration. This is the same role they have been playing, but in a “pull” environment they will be much more empowered.
  • Lastly, retain quality assurance team members to perform functional testing. I still suggest that the Business Analyst and/or a true Product Owner role exist to perform ongoing acceptance testing.

[/list]

.

Utilize User Stories: Kanban typically uses cycle time to size requirements. It may be heretical for me to propose this, but User Stories can accomplish the same thing, especially if the team members have already been trained on User Stories.

.

Manage WIP using functional velocity: Each functional team estimates the story points for their work on a story. As with Scrum, over time, each team will know their velocity and can commit to their work in progress (WIP) limits. They can then work towards a stable time-based velocity which can provide the same transparency as cycle time.

.

Team Size is managed by Story Points: The number of business analysts, software engineers and quality assurance team members is determined by the number of story points in the functional queue and ultimately the release schedule. As with Scrum, multiple small Kanban teams work better than one big one.

.

Self-Organizing is the same as a Kanban pull system: When a team member is done with a story, they go get more work from the queue.

.

Keep open spaces: This is just a good idea. Regardless of your Agile approach, one of the keys to success is having everyone in the same room.

.

It may sound complicated, but as with Scrum, after a few cycles the team begins to work out the kinks. I agree that over time, cycle time is a better approach for Kanban, but if you are moving from a Scrum model, it may be an easier transition to retain the use of Story Points, and I have seen teams be successful with this approach long-term.

.
Bottom line – keep it simple
.
.

Do you want to learn more about our approach to Kanban? Take our Kanban class in our virtual training classroom: Virtual_Agile

 

Interested in learning more about my approach to Kanban? Check out my online training Implementing Kanban for Project Management in my Agile Training store: http://buyagile.com/Kanban1

About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP
.
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.
.
Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the owner of Cape Project Management, Inc.
.
Cape Project Management, Inc.
Boston, MA 02129, USA
.
Contact: Dan@CapeProjectManagement.com

BE AGILE.™

Does your organization need an Agile Coach?

Does your organization need an Agile Coach?

Does your organization need an Agile Coach?As we love to say when answering many questions pertaining to Agile, “It depends.” Not the answer you want to hear, but let me elaborate. Extreme Programming (XP) introduced the term coach into the Agile community. The role was intended to both be a mentor on XP practices and a hands-on developer when needed. Scrum created the role of the Scrum Master with similar expectations but without the emphasis of being a hands-on developer.
The term, Agile coach, has become ubiquitous; however, it hasn't been used as XP intended. Quite often, the term refers to an external consultant and very seldom will you see it applied to an internal position.
I have played the role of Agile coach on and off over the last decade, and I didn’t always use the term coach. I was a coach when I was a program manager of a large Agile initiative; I was a coach when I was a functional development manager; and I was an Agile coach consultant hired to serve multiple Scrum teams. What was common for each of those roles was that I was the most experienced person in the room on Agile practices and I had a passion for passing on that knowledge to the teams I was working with.
In the first two instances, though I wasn’t formally named a coach, it was clear based upon my experience and willingness to share, that people felt comfortable approaching me for advice and discussion. Recently as an Agile Coach consultant, the same dynamic was true, but my role was more formal.

Do I need to be called an Agile coach to be an Agile coach?

Anybody with a passion for learning and sharing Agile best practices can be a coach. Becoming a coach is like becoming a leader. As with leaders, coaches can emerge from within a team.

What skills do I need to be an Agile coach?

[list type="disc"]

  • Active listening
  • The ability to influence without authority
  • Experience – with both success and failure
  • Patience
  • The right attitude!

[/list]

If they don’t work for me, how can I tell them what to do?

Here is a real situation I faced while coaching a Scrum Master. I had just sat through a very painful Sprint Retrospective:

Coach: “How did you feel that Retrospective went?”
Scrum Master: “It went fine, but the team is bored with them so I try to get them over with as quickly as possible.”
Coach: “Are you open to working with me to prepare something more fun and engaging for the next Sprint Retrospective?”
Scrum Master: “Definitely!”

In this situation, I didn't  immediately tell her what I would do differently, I gave her an opportunity to choose whether she wanted help or not.

How can I be an Agile coach for people that work for me?

I find this situation to be the easiest in many ways. My management style is very much in line with a typical coaching style. I work with the individual on their career goals and set a specific Agile maturity path based upon their experience and role. Some of these goals are around Agile best practices and engineering principles, and most often, it is about soft skills like listening, being self-organizing, and peer influencing.

So, back to the original question, does my organization need an Agile coach?

Every organization that is in the beginning or in the midst of implementing Agile needs someone who can be an Agile Coach. The question really should be, “Who should be playing the role of Agile Coach?”
If the Scrum Master is experienced and has the soft skills necessary, then the Scrum Master is often the coach. If there is a development manager or practice lead with the necessary background and desire, then they can be the coach. A team member can emerge as the coach if he or she has the passion and emerges from within the team.
If none of these internal candidates exist, you may need to look outside the organization—at least on a temporary basis—to fill this role. The ultimate goal is for everyone on the team to have a high level knowledge of Agile principles and practices, so that they can self-organize and continue to improve; resolve impediments; be productive; and truly enjoy their jobs. Then . . . there will no longer be the need for one individual to be a coach.

About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon this experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.
Dan has over 20 years of experience providing world class project management for strategic projects, direct P&L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the president of Cape Project Management, Inc.

email: dan@capeprojectmanagement.com

BE AGILE.™

Who makes a better Scrum Master: a developer or a project manager?

Who makes a better Scrum Master: a developer or a project manager?

Who makes a better Scrum Master: a developer or a project manager?

I am guessing that this is a contentious topic, so it is that much more fun to talk about…

The Agile Manifesto was written by software developers. There weren't any “traditional” project managers in attendance, so, it is safe to assume that Scrum Masters were expected to come from the ranks of software engineers.

I attended Scrum Master training with Ken Schwaber in 2000 and again in 2011, and on both of those occasions, it was clear that the role of a project manager was not needed or wanted on Scrum projects. I agree with the sentiment about the role of project manager, but I still believe it is acceptable and even sometimes highly successful to have a former project manager become Scrum Master.

I am a project manager by education (Industrial Engineering), by training and by certification (PMP) and ultimately by birth. I have been managing primarily software development projects since 1996, even though the last time I coded was using Fortran in college, unless you count my ability to use <bold>html</bold> in my blog. Given my technical limitations, I still consider myself an above average project manager and an even better Scrum Master, not because of my background in either discipline, but because of my real life experience and exposure to incredible leaders and people managers throughout my career. Early on, about 20 years ago, I was told by my boss and mentor, "Just because you are right, that does not mean people will listen to you or even agree with you." I was a practical project manager surrounded by academics, artists and other creative minded people. In order to successfully lead them and organize them I had to develop skills in listening, persuasion and influencing without authority. This began my path to truly understanding servant leadership.

So, the reality is that the "average" project manager or developer makes a poor Scrum Master. The “best” Scrum Masters will be found by identifying individuals that are well-trained, educated and passionate about Agile and servant leadership, regardless of their background.

It is well known why some project managers make poor Scrum Masters. They use their “command and control” attitude on the Scrum Team. What most Agilists with software development backgrounds don’t understand is that many project managers who were trained as professional project managers, were never intended to use a command and control style. I was trained early on in my career as a project manager that we were most effective if we could motivate and lead our teams without using a carrot or a stick, but by engaging them in the vision and ultimate success of the project. PMI actually promotes the concept of influencing without authority. Throughout my career as a project manager, I never had any functional power. The developers never reported to me, I wasn't the technical expert, so how was I successful? By being a servant leader! We were trained to remove impediments, make sure there were minimal distractions for the team, and you know what? We were trained when projects were high-risk, we should meet every day with the team to remove impediments. Sound familiar? Granted, as with Scrum Masters today, most project managers were assigned from the ranks of functional managers who were familiar with a directive style of management, and many loved the “hero” status reserved for those overachievers, but that was never the intent. Those project managers that I worked with, who were trained as I was, and those that I trained later in my career would make excellent Scrum Masters today.

It is the same story with developers. There are many developers who see being a Scrum Master as a promotion. It gives them the opportunity to play the elusive “tech lead” role and drive the technology. How can a developer with a strong opinion on how something should be built sit back and let the team self-organize around a solution that they don’t technically agree with?

To be an effective Scrum Master, you have to embrace the core values of the Agile Manifesto. I believe there is an equal chance of both failure or success when selecting a Scrum Master from the ranks of developers or project managers. Regardless of where you find your Scrum Master, it is much more important that they have the requisite skills needs to be a servant leader; including trust, passion, and enthusiasm for both Agile and for helping their teams succeed.

Dan Tousignant, PMP, PSM I, CSPO, PMI-ACP, etc., etc., etc.
Cape Project Management, Inc.
www.BostonAgileTraining.com
www.AgileProjectManagementTraining.com

BE AGILE.™