Zombie Manifesto

Who would have thought that a year after publishing Zombie Project Management that I would be asked to brief a Federal Agency (which is not to be named at this time) on the topic.  As part of my briefing, I will be including the Zombie Manifesto. Nobody has said I have lost my sense of humor.  Then again, nobody has told me I have ever had a sense of humor.  I look forward to writing a blog post next week after the briefing.  "Briefing" makes me talking for over an hour sound so official!

Become a Signatory! Leave a comment below

PMI Agile CoP Retrospective

Agile CoP Retro

When you think of spending a Saturday afternoon among friends and colleagues, do you picture yourself sitting in front of your computer, collaborating for three hours on a web-based tool and discussing what is working and what could work better? Well, that is exactly what a group of us did. It was time for the quarterly PMI Agile Community of Practice (CoP) retrospective. We couldn't all be in the same physical location so some of us from the community jumped online and tried to make the world (or at least our CoP) a better place.  When you look at the graphic above, you may be left scratching your head, if you are neither an Agilist nor a member of the PMI Agile CoP. If you are either, I hope you nod in recognizing the mechanism we used to interact and make our Agile Community of Practice a better place for us all to belong.

Community of Practice

You could describe us as a motley crew of discontents and zealots. You could also describe us as a passionate group of Agilists drawn together, with the hope of helping the PMI community discover the value of Agile practices and approaches.  We all hold a sense of belonging to our community.  We all believe in the altruistic sharing of knowledge, methods, stories, cases, tools, and documents.

Retrospective

Generically speaking, a retrospective meeting is held at the end of a scheduled event or time interval. With the aid of a facilitator (in this case Brian Bozzuto), a team discusses what went well and what could be improved during the next interval or prior to the next scheduled event.  The meeting is time-boxed to help ensure it doesn't just turn into an out-of-control complaining session.  When properly facilitated, you come out of the meeting with an actionable list for improvement. Though I always recommend doing retrospectives in person, actually having the retrospective takes priority. Do it wherever you can however you can.  Successful teams need to take the time to have retrospectives if they have any chance of improving what they do.

PMI Agile CoP Quarterly Retrospective

The leadership of this community recognizes that as our community grows, some things will work and some challenges will need to be overcome (zoom into the graphic to see what we thought).  One thing is for certain: with almost 14,000 members, our PMI community has a lot to offer both members and non-members.  Every minute of that Saturday afternoon was well spent.  I hope this post and the link to the Cacoo graphic provides some transparency into what we've been doing the last three months.

Source:  This post was originally written and published by me on the PMI Agile Community of Practice blog

TDD - Tool Driven Development

In order to realize the greatest benefits in application development, it is recommended that you use good engineering practices.  Those practices include continuous integration, paired programming and TDD (Test Driven Development).  Unfortunately, when arriving at a new coaching engagement, it is common that a tool vendor has arrived on the scene before the Agile (engineering and process) coaches.  Just as many are sold on Agile being a silver bullet, I find people are equally sold on the idea that a tool can solve all of their problems. Are clients wrong to assume an enterprise “Agile” tool can transition them away from a “Waterfall” tool?  I'm sure that is what the tool vendor told them.  Though I would agree some of the leading providers do offer more lightweight solutions, the truth is some people (after the sale) get frustrated when they realize their tools need to be customized, to align with their business processes.  Unfortunately, I have seen that customization not happen.  Instead, customers struggle with the tools they have implemented.  They change their development and delivery process so they can use the tools.  They start to practice TDD (Tool Driven Development).

When I show customers they can accomplish what they need with index cards, painters tape, and Sharpies, the next question is how can they modify the tool to align with reality.

Always remember the first value of the Manifesto: Individuals and interactions over process and tools.  Fix your processes first.  Then, and only then, should you look to a tool for efficiencies.

Image Source: Pictofigo

Mieruka & Real World Examples

I just submitted my paper to be a speaker  at the PMI Global Congress on the topic of Visual Management Systems (VMS).  Some may know VMS as VCS (Visual Control Systems).   According to Wikipedia, Visual control is a technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity. In the Toyota Way, it is also known as mieruka (making visible).  I love the wild and endless variety of real world mieruka! Today I was driving through a school zone when something caught my attention.  It wasn't a police officer yelling at cars to slow down.  It wasn't a sign that said "Slow Childern at Play".  It was a speed limit sign with a radar speed sign attached to it.  On the top you see the proposed speed limit and on the bottom you see the actual.  It wasn't snapping pictures of people speeding passed.  To the contrary, all it was doing was bringing attention to actual vehicle speeds.  As I wrestled to get my speed below 25MPH, I was amazed how well it worked.

Everyone around me slowed their vehicles down, with no more coercion than knowing their speed through real-time visualization control.

Media Source: Peds.org

Official PMI-ACP Numbers

The PMI-ACP pilot has concluded and the Agile Certified Practitioner certification is officially one month old.  The numbers are in!  Per PMI Today, January 2012 concluded with 542 PMI-ACPs.  Not too shabby for its first month.  The PMP is still PMI's shining star, at 4047 new PMPs.  What surprised me were the numbers of PMI's other certifications.  Only 11 people got the PMI-SP in January.  It makes me wonder, what is the PMI-SP certification's value and longevity in the PMI ecosystem?  I ask because the PMI-ACP reached a number in one month that took the other certification a few years. And so it begins.  Will PMI-ACP be the next PMP?  What do you think?

MVP for PMI Agile Exam Flashcards

With the PMI Agile Certified Practitioner (ACP) exam celebrating its first month in the wild, I am sure you are already seeing a lot of study aids and prep courses being offered.  Full disclosure, I do offer ACP prep courses and I also offer PMI Agile Exam flashcards.   Wait, did you read that correctly?  Yes, you did.  I want to ensure there is a source of relevant study material available to the masses so I created the PMI Agile Flashcards website and have an iPhone app (that needs to be submitted to Apple for approval). As a co-lead for the PMI ACP support team, we are tasked with creating a knowledge base of relevant information for the ACP exam.  Think of it as a Wikipedia for the PMI-ACP but within the PMI.org website.  Though that's all well and good, creating a glossary for both trainers and certification aspirants is not a study aid.  I still see the need for things like study guides and exam prep tools.  I think back when I was preparing for the PMP.  Reading the PMBOK Guide was a wealth of information but I needed something to put it into context.  It wasn't until I read Rita Mulcahey's book that it all made sense to me.  I also created a deck of flashcards for myself to help me prepare for the PMP exam.

Fast forward to today, for those of you who are looking for a study guide for the ACP, Mike Griffiths (the other PMI ACP support team co-lead) has just completed his ACP Exam prep book. I am releasing my Minimum Viable Product (MVP) for my PMI ACP Exam Flashcards. If that combination worked for me to prepare for the PMP, I hope it works for you for the ACP.

If you are wondering what I mean by MVP, I got the term from the Eric Ries book The Lean Startup.  I knew that I needed to get something out there now, get feedback from customers, and iterate the product.  The good news is, I know the questions and answers on the flashcards are relevant to the exam.  All I needed was to get something out there that people could use.

My MVP

1. The first 75 flashcards loaded

I have loaded 75 flashcards into the database.  I know they are all relevant because I took (and passed) the ACP exam and because I have been involved during the certification development and am now involved to support it.  I've been involved in the Agile and PMI communities for a while now.  I want good quality prep materials made available to people. I don't want them to just pass the exam.  I want them to learn something.

2. All flashcards map to one of the six domains

• Value Driven Delivery

• Stakeholder Engagement

• Boosting Team Performance Practices

• Adaptive Planning

• Problem Detection and Resolution

• Continuous Improvement (Product, Process, People)

3. All flashcards map to the two areas you will be graded on

• Tools and Techniques

• Knowledge and Skills

4. 20 free flashcards to view without login

I figure you'll know if this product has value for you within 20 flashcards.  After that, you'll probably want to create a login so you can keep track of your progress.

5. 20 free flashcards with progress tracking with login

So, you created a free account.  You'll now be able to visualize your progress as you go.  By navigating to the progress screen, you'll be able to navigate back to cards that you got incorrect or skipped earlier.  Since you're still using a free account, you'll have access to 20 flashcards.

6. Access to all flashcards with paid account

This is where we wrap it all together.  The goal is to have a few hundred flashcards in the system.  You can get started now with the first 75.  As the database grows, random flashcards will appear as "unviewed".  Just check your status before you begin and you know where you stand.

What is next?

• Add more flashcards

• Make some changes in the User Interface to make it easier to navigate

• Get feedback from customers

• Refine the product or pivot

• Get the iOS and Android versions completed

Note: A few of the links are Amazon affiliate links.

Ready and Done

When leading development teams, I see most of the wasted activities happen during the development phase.  If work is not ready, before the team begins development, there can be delays waiting for clarifications from the business.  If acceptance criteria is not clearly defined, before the team begins development, work can go on and on trying to appease the customer.  What your team needs is a clear definition of "Ready to Work" and a clear definition of "Done with Work".  Though definitions vary from team to team and organization to organization, it's imperative that you do it.  It's also imperative the team writes the definitions, not someone in an ivory tower. As with all of our clients, I stress the need to have a minimal agreement on both definitions before work is started.  When defining both the entrance and exit criteria, all major parties within the team need to be involved, to lower risks that something will be missed.

Below are examples of the definitions or ready and done.  Notice that we consulted Analysts, Testers, and Developers.  For your team or organization, you may consult UX designers, DBAs, Architects or others.  Don't make your definitions overly onerous.  Just create something that is just good enough and go from there.

Example of a Definition of Ready

• Analyst – User story sufficiently defined and mapped from requirements

• Tester – Acceptance criteria developed

• Developer – User story is estimated and no known blocking dependencies exist within the sprint

Example of a Definition of Done

• Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection

• Tester – Test cases pass. All critical and high severity bugs fixed and other bugs identified and tracked

• Developer – Deployed to test environment and Code Review complete

So, what does your team require as part of your definition of ready or done? Do you have definitions?

As a side note, if you're preparing for the PMI-ACP exam, remember the team is responsible for the definition of done.

Image Sources: Pictofigo

A Strategy for Code Reviews

I was coaching an organization the other day where they are trying to increase code quality. They believe they can accomplish this by increasing the frequency of code reviews. Currently, their solution is to get everyone into a room on a weekly basis, with junior developers demonstrating what they did and senior developers offering constructive feedback. If you've been reading my blog for a while now, you'll know that I usually find structured lengthy meetings as a wasteful activity. I'm not saying there isn't value in them. I'm just saying their cost is too much, relative to the value.

Weekly Code Review

Because the teams are trying to increase their delivery velocity, they are being forced to review their code delivery policies and rules. The weekly code reviews are creating too much of a delay. If a developer finished his or her feature on day one, they have a whole week to wait for the code review. If any changes are recommended, they lose an entire week because they still have to make the updates and get another review. The quality may be high but the velocity is low.

Pairing

My recommendation was the teams should begin pairing.  Upon review of their defined policies, it did not say they had to have a formal weekly code review meeting.  What it did say was no code would be merged into the trunk until another set of eyes had reviewed it.  By having a "code review" developer sit with the active developer, as he or she wrote code, it could be reviewed in real time and satisfy the policy.  The one week feedback loop would be shortened to an immediate feedback loop.

The Compromise

Paired programming can be a hard sell.  Management can find it hard to understand having two perfectly capable developers working on one piece of code.  But, if you look at the cost of waiting an entire week to get feedback and also having a group of developers stop work to attend a code review meeting, you can see there is a lot of wasted time and effort.  When I asked about this, I was told that the meeting was also an opportunity for developers to learn about other areas of the system.  My counterpoint was to rotate the pairs, to also offer a learning opportunity.

Because the teams would not agree to do formal pairing, but they certainly see the value in it, they decided to have a different (floating) code reviewer every day.  He or she will make themselves available the entire day to review code as needed.  I don't completely agree with this approach but it's certainly better then a weekly code review meeting.  They will be exposed to new areas of the system and the feedback loop will be shortened.  My hope is, in time, they will realize that having that second set of eyes sitting there full time will be the most efficient appraoch.

Image Quality by Pictofigo