Agile Flashcards

To celebrate the 10 year anniversary of the signing of the The Manifesto for Agile Software Development and the upcoming launch of the PMI-ACP^sm Agile certification, I have been working behind the scenes on a new mobile learning tool.  After realizing how congested the PMP market was, I decided to leverage what I learned from PM Prep Flashcards and apply the code toward agile learning.

So, are you going to take the PMI-ACP^sm certification exam? Would you like to be notified as soon as we're done with a simple learning tool that you can use on your iPhone, iPod Touch, or iPad to prepare for the exam?

Get on the list!

---

PMP® is a registered trademarks of the Project Management Institute, Inc. PMI-ACP^sm is a service mark of the Project Management Institute, Inc.

Speaking at AgileDC 2011

I'm happy to announce that I will be speaking at AgileDC 2011.  My session, When PMI Introduced the Elephant in the Room, will be part of the Enterprise Agile track. Last October I entered the Gaylord National with a little trepidation.  The PMI North American Congress was taking place and I found out that several people I admire in the Agile space were going to be attending and speaking.  Leading up to the major PMI event, I was hearing a lot of chatter about these "heretics" who were going to be presenting.  In Washington DC, the PMP was king and few in the Federal space wanted to hear anything about adaptive planning, continuous elaboration, or focusing on delivering value to the customer.  Project Managers were expected to predict the future, define process and then make damn sure you followed it, regardless if anything ever got delivered.  So, I was very much surprised as I walked through the Gaylord and noticed poster after poster, display after display.  "Are you Agile?"

Every Agile session I attended, PMI Vice President of Information Technology, Frank Schettini introduced the speaker and told the audience that he leads the team that is responsible for delivering value to PMI’s members, volunteer leaders, certification holders and staff through innovative and reliable technology solutions. He said that he was a strong supporter of the Agile Community and so was PMI.

Though the audience at one of the first Agile sessions was almost hostile towards the presenters, by the time Michele Sliger gave the final session on the final day of the conference, there was buzz in the halls of the Gaylord about how "this Agile thing" had taken the conference by storm.

Agile was about to cross the chasm and PMI was going to make sure we made it to the other side.

But first, introductions were in order.

---

I will talk about the current state of Agile and how I see the landscape changing, with the introduction of the new PMI Agile certification.  I will compare and contrast the PMI-ACP^sm to the PMP® as well make some predictions for things to come.

Now, don't come to just hear me talk!  This year, the keynote speakers will be Agile luminaries Ken Schwaber and Sanjiv Augustine.  It should a great conference.  If you're interested in 15% discount, please contact me directly.

Getting on the Agile Coach List

Almost two months ago, I left my gig advising a Federal PMO to join LitheSpeed. LitheSpeed offers premium Scrum and Agile consulting, coaching, and training services. So, what do you do when you win work? Well, you put the word out that you're looking for qualified people! So, are you an Agile coach who would like to be considered for our current and future engagements? Complete the form and you'll be on the list.

Don't see the Google form? Try this link

Drawing by Pictofigo

Simple Cheat Sheet to Sprint Planning Meeting

WHAT IS SPRINT PLANNING?

Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint.  In sprint planning, the entire team agrees to complete a set of product backlog items.  This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.

WHO DOES IT?

Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.

HOW DO WE PREPARE?

Ensure all sprint candidates meet the team’s definition of ready.  In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.

• Assign a relative story point value
• Remove dependencies
• Create testable examples
• Define acceptance criteria
• Meets INVEST criteria

WHAT IS THE BACKLOG?

The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner. 

ENSURE RIGHT SIZING BACKLOG ITEMS

Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint.  In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice.  Therefore, stories should not be incomplete or process-based as a horizontal slice.

CALCULATING A COMMITMENT

To calculate a commitment, mature teams may use a combination of both team availability and velocity.  However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the their capacity.

DETERMINING VELOCITY

First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint.  Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.

DETERMINING CAPACITY

For teams without a stable velocity, each team member should provide three simple measures to determine capacity.  First, what are the number of ideal hours in their work day?  Second, how many days in the sprint will that person be available?  Third, what percentage of time will that person dedicate to this team?

THE PLANNING STEPS

1. Remind the team of the big picture or goal
2. Discuss any new information that may impact the plan
3. Present the velocity to be used for this release
4. Confirm team capacity
5. Confirm any currently known issues and concerns and record as appropriate
6. Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
7. Present proposed product backlog items to consider for the sprint backlog
8. Determine the needs, sign up for work, and estimate the work owned
9. Product Owner answers clarifying questions and elaborates acceptance criteria
10. Confirm any new issues and concerns raised during meeting and record
11. Confirm any assumptions or dependencies discovered during planning and record
12. ScrumMaster calls for a group consensus on the plan
13. Team and Product Owner signal if this is the best plan they can make given what they know right now
14. Get back to work

// If your team is new to Scrum, download a copy of the Sprint Planning Cheat Sheet //

Drawings by Pictofigo

Becoming a PMI R.E.P.

As you may know by now, I left my gig advising a Federal PMO to join LitheSpeed as a Senior Manager. LitheSpeed offers premium Agile software development training, coaching and management consulting services. My relationship with the organization actually started several years ago, when I attended ScrumMaster training to earn my certification. (You can't be a Certified ScrumMaster through the Scrum Alliance unless you get your training from a Certified Scrum Trainer®.) Well, the world is evolving and so is LitheSpeed. See, Certified Scrum Trainers (CSTs) play a vital role within the Scrum Alliance. They are the only ones licensed to teach Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) courses. Stringent certification requirements are imposed on CSTs to make certain that only those who are qualified to meet the commitment are entrusted to engage in this role on behalf of the Scrum Alliance.

Well, what about those out there who are members of the Project Management Institute? What about those seeking the upcoming PMI® Agile Certified Practitioner (PMI-ACP)SM certification? If you want to qualify to sit for the PMI-ACP, you will need 21 training hours in an Agile-specific curriculum. To ensure members of the PMI know LitheSpeed offers quality training that will help satisfy that requirement, we applied to and were approved to be a PMI Registered Education Provider (R.E.P.).

What does it take to become a PMI R.E.P.? Applicants must complete a 33-page application, which includes a strict quality review of both the trainers and the curriculum. The first class we submitted and got approved was our Certified ScrumMaster course; next will be our Certified Product Owner and PMI-ACP Prep courses. As an R.E.P., LitheSpeed has been approved by PMI to issue Professional Development Units (PDUs) through the PMI website. Our goal is to equip our trainees with tools they can apply on current and future projects, not just help them qualify to take an exam.

I know this post sound a little like a press release.  But, I have to admit, applying to become a PMI R.E.P. is no cakewalk.

If you would be interested in attending one of my upcoming public training sessions or would be interested in me providing a private training session, shoot me an email!

PMI® and the PMI® Registered Education Provider logos are registered trademarks of the Project Management Institute, Inc. PMI-ACP is a service mark of the Project Management Institute, Inc.

Waste In Software Projects

This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman.  In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used.  The question this evening was, for the 45% of the features that were never used, what was the cost incurred?  Well, I can tell you it's probably a lot more than 45% of the budget!  What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment.  If a feature or product is never used, it's waste. But, since XP2002, have we learned our lessons?     Are we still delivering features that customers will never use?  I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc.  The collection of data was just a distraction from the actual blog post.  Thank you to those to participated.

Empirical or Definitive

Ever heard of the cone of uncertainty?  The cone shows the historical error at certain time periods in a tropical cyclone forecast.  What happens today and what has happened in the past is pretty much all we know.  We can certainly use all kinds of scientifically proven processes or models to try to predict the future.  But, in the end, we won't know what tomorrow will bring until tomorrow.  If you are dealing with machines, you should be able to predict upcoming events with relative certainty.  If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none. We need to assume that baselines may change significantly during a project or in life.  In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins.  You do everything you can to lay it all out, attempting to account for every possible variable.  Unfortunately, you don’t know what tomorrow will bring.  So, the further out the schedule goes, the greater the risk something is going to change.  What’s it going to be?  Is scope going to change or maybe the schedule will slip?  With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown.  Even some of the unknowns aren't even known.  Just accept it!  You’re not the Amazing Kreskin.  You can’t predict the future.  The only thing that is guaranteed is something is going to change.  So, plan for that change.  Know the goal you’re trying to reach.  Keep your eye on that goal.  Now, do what you do.  Develop, lead, manage… it doesn’t matter.  What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again.  Make some adjustments and repeat.  You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it.  You can not steer a hurricane, only plan for it.  You can not prevent change…  Can you guess what comes next?  That’s right, you plan for it.

Organizing Around Teams

Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100 percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions? In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Two, team members never seemed to have time to just focus on one thing and get it completely done.

Status quo organizes teams around projects

• Projects are initiated
• We beg, borrow and steal, looking for the right people to work the project
• We pull a few hours from here and a few hours from there
• Everyone is "fully utilized" by working on several projects at the same time
• When the project is completed, we release some portion of each person’s hours back into the pool and start again
• Endless resource-management frustration

Bring the right projects to the right teams

• Teams focus on one or two projects at a time and get them done quickly
• Management prioritizes projects and queues them up for the appropriate teams
• May need to move a few people around but hopefully not many and not constantly
• Much of the resource management problem goes away
• We also get fewer simultaneous projects, more focus, and more speed of delivery

Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.

Organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.