By the Book

By the Book

I found Mike Cohn’s posting Don’t Blindly Follow very curious because it seems to contradict what many luminaries of the Agile community have said about starting out by strictly following the rules until you’ve really learned what you’re doing.

In one sense, I do agree with this sentiment of not blindly doing something.  Indeed, when I was younger, I thought it was quite clever of me to say things like “The best practice is not to follow best practices.”  But then I discovered the Dreyfus Model of Skills Acquisition and that made me realize that there’s a more nuanced view.  In a nutshell, the Dreyfus model says that we progress through different stages as we learn skills.  In particular when we start learning something, we do start by following context-free rules (a.k.a., best practices) and progress through situational awareness to “transcend reliance on rules, guidelines, and maxims.”  This is resonates with me since I recognize it as the way I learn things and when I can see it in others when they are serious about something.  (To be fair, there are people that don’t seem to fit into this model, too, but I’m okay with a model that’s useful even if it doesn’t cover every possibility.)  So, I would say that we should start out following the rules blindly until we have learned enough to recognize how to helpfully modify the rules that we’ve been following.

Cohn concludes with another curious statement: “No expert knows more about your company than you do.”  Again, there’s a part of me that wants to agree with this, but then again…  An outsider could well see things that an insider takes for granted and have perspectives that allow them to come to different conclusions from the information that you both share.

I find myself much more in sympathy with Ron Jeffries’ statements in The Increment and Culture: “Rather than change ourselves, and learn the new game, we changed Scrum. We changed it before we ever knew what it was.”  This seems like it would offer a much better opportunity to really learn the basics before we start changing this to suit ourselves.

When people see my ­­business card or email signature, they sometimes question the letters beside my name: what do they mean,should they try to get them too, etc.  One set of those letters seems to jump out a bit more as a question than others – the PMI-ACP.  I think it’s because they see “PMI” and wonder what it’s about.  I’ve even had some people ask if it’s misspelled.  So, to clear the air, I’ll explain it…

The PMI-ACP is an Agile certification that is administered by PMI which signifies that you understand, and have experience in, implementing Agile methods.  There is a combination of an exam and the project experience you have in Agile projects to acquire the certification.

If you are still a bit confused, the Project Management Institute is considered to be the go-to source for all things project related.  As such, they are seen as the foremost authority on the processes that are used to deliver projects.  Over the last 5 years or so, as Agile has become increasingly the favored way to deliver projects, the PMI has added Agile to their Project Management Book of Knowledge (PMBOK) and added the PMI-ACP certification.

So far this doesn’t sound like much of a big deal, right?  Well, let’s see why it is…

As I mentioned, in the world of project management, the PMI is seen as the ‘governing body’ when it comes to ways to deliver projects.  Anyone that works on any project knows there are rules that PMI has set forth on managing projects.  Since the influx of projects using Agile processes, more and more project managers need to be apprised of the rules that change or the various ways that PMI has suggested instilling the Agile processes.

With the increase in Agile projects, there is a growing need for required guidance for these projects.  Companies are looking to their project managers and team members to gain the knowledge and expertise to ensure successful projects.

By having Agile experience and taking the exam, you too can acquire your PMI-ACP so that you can show your fellow project managers and team members that you have the experience and knowledge to help lead Agile projects effectively and successfully!

In order to acquire your PMI-ACP, you first should acquire the required experience in Agile projects.  PMI’s required number of hours is 1500 on Agile projects.  This can be done using any of the Agile methods and on multiple projects.

In addition to the project experience, you will need 21 hours of Agile education, which you can gain in numerous ways, including the PMI-ACP Exam Prep.

After you have worked on Agile projects, then you will need to take the PMI-ACP exam.  Now, most people get a little squeamish when talking about taking an exam, but I’m here to tell you not to worry!  There are many ways to study for the exam so that you can breeze through it, but the easiest being to take a class that will prep you for the exam.  Check out the PMI-ACP Exam Prep offered by CC Pace—it will give you an extra boost in your knowledge, your 21 hours of education, and some practice of taking an exam!

The PMI-ACP is seen differently by different people; some see it as just a set of letters while others see it as a way of exhibiting their knowledge of Agile processes, as accepted by PMI.  Either way, it is something that will most definitely show your team you accept the Agile mindset and are embracing the shift that project management has taken to follow the Agile processes!

In a previous blog, “The Reality of T.E.A.M”, I talked about Agile teams being dedicated, or part of a ‘permanent’ team that focuses on a single solution and remains together over time.  Another big factor of an Agile team is that they are cross-functional in nature.

What is a Cross Functional Team?    
When the topic of cross-functional teams comes up, there seems to be varying opinions that come out.  What does it mean when I refer to teams being cross-functional?  Does everyone on the team have to be able to do every job?  Do all team members have to know every detail of everything that goes on inside the team?  Does the team have to ensure that they can complete their solution?  Let’s look at what cross-functional means for Agile teams that I work with.

If you want to define it, you will most likely find that it means something like “a group of people with different functional specialties or multidisciplinary skills, responsible for carrying out all phases of a program or project from start to finish.”[1]  If you stick with this definition, you may find that you do not have to have a team where everyone on the team knows how to do every job on a team, but more that it is meant to keep members focused more on their role in moving the product forward than on their title.

Now that you’re on a Cross Functional Team
When the members of a team hear they are to be cross-functional, I’ve seen them get a little uneasy thinking they have to become something they may not want to be or learn to do things they don’t want to do.  I call this their ‘mini identity crisis’ because these team members are so centered around their title defining what they are supposed to do, they lose sight of what it means to be a team.

Team members will hopefully come to understand that becoming part of a cross-functional team means they will be focusing more on their role as a team member than on what their title is on their HR file.  Being a cross-functional team member is about ensuring you chip in whenever necessary and do as much as you can to ensure the solution is complete, and as good and valuable as it can be.

It’s not necessarily important that all team members know how to do everything, but it is important they work together, embracing common Agile principles from the Agile Manifesto and Principles, as well as principles that are found in Agile methods, such as “’Collective Code Ownership’ in Extreme Programming, which ensures the entire team owns the code and ‘Self-Organization’ in Scrum, where the team organizes themselves to get the job done.

Where does an Agile Coach fit in?
When coaching cross functional teams, I try to support and help them understand they won’t be losing their identity, but they are going to become part of a larger solution.  I emphasize that they’re not ‘against each other’, or ‘apart from each other’, but ‘for each other’.  I’ve found it’s important for team members to communicate and collaborate so they feel like part of a team instead of a pool of resources thrown together and asked to feel and behave like a team.

For all you sports fans—A Sports Analogy
Cross-functional teams remind me of football teams.  In football, there are multiple positions, both on the offense and on the defense.  While each member of a football team is most likely drafted onto the team to play a specific position, such as protecting the quarterback, the skills they possess for that position may also translate to other positions on the team.  For example, the player that protects the quarterback can use those same skills to get around the protection of the other team’s quarterback and sack him.  Just like a football team has players who are able to move to different positions in order to win the game, Agile teams use the same idea to produce the best possible solution!