Agile Program and Portfolio Management – Agile2012 Slide Deck

Written by Mike Cottmeyer Thursday, 16 August 2012 04:13

220 people signed up for this talk but I think the room was at capacity at about 125 or 150.  Great turnout and lots of great discussion.  Mary Poppendieck came to my talk and said it was excellent.  That is very humbling.  Even better that she came because she heard the talk yesterday was so good ;-)  Flattered and blushing!

Here is a link to the .PPT version:

Join the conversation. There are currently 7 comments.

Enterprise Agile Transformation Strategies – Agile2012 Slide Deck

Written by Mike Cottmeyer Thursday, 16 August 2012 08:07

Thanks to everyone that showed up for my talk. We had a great turnout and a ton of great conversation. As promised, here is the deck.

Here is a link to the .PPT version:

Join the conversation.

Best quote so far from Agile 2012

Written by Derek Huether Thursday, 16 August 2012 06:20

If you’re curious what is happening this week, the entire LeadingAgile team is here in Dallas, Texas at Agile 2012.  Dennis and Mike are presenting and Dean, Rick, Jesse, and myself (Derek) have been helping PMI man their booth, communicating the facts of the Agile Community of Practice and the Agile Certified Practitioner certification.  This has been an amazing experience and I would strongly recommend attending next years event.

I was going to wait to write a blog post until I got back home.  But why wait?  The most “quotable” event so far happened yesterday when I was in Jeff Patton’s session.  He said

We don’t need an accurate document. We need a shared understanding.

The message was simple but powerful and it resonated with me. I immediately jumped onto Twitter and posted it.  I credit Esther Derby retweeting it to her (over 6000) followers for so many retweets.  That quotable moment has been just one of many I’ve had the last few days.  It’s really too bad there isn’t more time to hang out with and learn from more of these people I’ve met the last few days.

Join the conversation. There is currently 1 comment.

No Excuses

Written by Rick Austin Tuesday, 14 August 2012 08:31

I’ve been an avid photographer for 10+ years. There have been times where I’ve fallen into a trap. A trap where I didn’t shoot because conditions weren’t perfect which often made me convince myself that I needed to be somewhere else to do so. Somewhere else that has great views, cool vistas, and the list goes on. I also fell into the “equipment” trap where I just need one more lens, or flash, or tripod, and the list goes on. Conditions will never be perfect, we’ll never have every piece of equipment we think is needed, and I learned that neither of these stand up as an excuse.

I started a journey on November 17, 2010 that helped me break out of those excuses. I was invited to participate in a photo-a-day group that required each of us to shoot one photo each day. We posted and shared our photos with each other throughout the year. If you’ve never participated in something like this it is an eye opening and somewhat stressful experience.

What I found is that I could no longer make excuses. I moved forward with an intense focus for getting the shot, being successful in spite of current conditions or the state of my equipment. I also had a personal goal of not just taking a picture, I wanted each shot to be something I could be proud of; there might be debate on whether or not I met that goal ;-) That year pushed me out of my comfort zone and caused me to grow more that year as a photographer than any other time in my life. I did not allow excuses to limit me, I just did it.

When organizations begin an agile transformation they often have a similar mindset. I hear a number of excuses why the transformation will fail – the business is not going to change, I don’t have appropriate training, we can’t co-locate teams because of expenses required to do so, we don’t have the skills necessary to write automated tests, we need better tools, and the list goes on. When approaching a transformation there must be fundamental capabilities in place and we’ll identify those needs and make sure training and coaching are provided to do so. This is similar to the need for a photographer to have an understanding of lighting, exposure, and composition. Yes, address the fundamentals but even with that, a transformation is difficult, uncomfortable, and stressful – a perfect environment for excuses.

As I experienced with the photo-a-day project, the act of doing it made each day better. Experiences I gained with every single shot made the next one easier. I built upon each day’s lessons to make the next day an improvement on the last. With an agile transformation, each day will bring new lessons and experiences that make tomorrow easier. Challenges today will become routine capabilities in the future. Tomorrow will bring greater challenges than today and by continuing to move forward you build confidence in your abilities and I bet you’ll look with surprise and delight at how far you’ve come. I was very proud of my accomplishments during my photo-a-day project and I know those challenges made me a better photographer. Not buckling in to excuses kept me moving forward. As you continue your journey don’t allow excuses to hold you back, get the shot.


Note: The photo above is a collage of all of the photos from that year. If you would like to see the whole set then click this link.

Join the conversation. There are currently 4 comments.

Simple Cheat Sheet to Sprint Planning Meeting

Written by Derek Huether Thursday, 9 August 2012 08:36

Scrum ImagesWhat is it?

The purpose of the Sprint Planning Meeting is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

Who does it?

Sprint planning is a collaborative effort involving:

  • ScrumMaster – to facilitate the meeting
  • Product Owner – to clarify the details of the product backlog items and their respective acceptance criteria
  • Entire Agile Team –to define the work and effort necessary to meet their commitment to complete product backlog items

Before You Begin

Ensure all items to be discussed meet the teams definition of “ready”, to include (for example):

  • relative story point value
  • dependencies removed
  • testable examples
  • clearly defined acceptance criteria

All items to be discussed reflect the greatest needs as identified by the Product Owner at the time of the meeting.  There needs to be a general understanding (and agreement) of the acceptance criteria for these top-ordered backlog items.

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Plan Based on Capacity

Mature teams may use a combination of team availability and velocity to forecast what product backlog items can be finished during the sprint.  New teams may not know their velocity or it may not be stable enough to use as a basis for sprint planning.  In these cases, new teams may need to make forecasts based solely on the team’s capacity.

Determining Velocity

The velocity of a team is derived by summing the story point estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.  Never use the velocity of another team to plan your sprint.

Determining Capacity

For teams without a stable velocity, the capacity of a team could be derived from three simple measures for each team member:

  • Number of ideal hours in the work day
  • Days in the sprint that the person will be available
  • Percentage of time the person will dedicate to this team

The Planning Steps

  1. The Product Owner describes the highest ordered product backlog item(s)
  2. The team determines and prioritizes what is necessary to complete that product backlog item(s)
  3. Team members volunteer to own the work
  4. Work owners estimate the ideal hours they need to finish their work
  5. Planning continues while the team does not exceed determined capacity
Image Source: Pictofigo Premium
webinar ad
Join the conversation. There are currently 4 comments.

Public Training Locations

Upcoming Training Classes

2-Day Agile Requirements Course
2-Day Agile Requirements Course
April 7-8 Orlando, FL
Advanced Agile Development with Dr. Alistair Cockburn 3 Day Master Class
April 14-16 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
April 14-16 Reston, VA
3-Day PMI-Agile Certified Practitioner Course
April 28-30 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
May 5-7 Denver, CO
2-Day Agile Requirements Course
May 15-16 Alpharetta, GA
2-Day Certified ScrumMaster Training Course
May 19-20 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 9-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 16-18 Reston, VA
2-Day Agile Requirements Course
June 23-24 Orlando, FL
2-Day Agile Requirements Course
July 10-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
July 21-23 Westminster, CO
3-Day PMI-Agile Certified Practitioner Course
August 11-13 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
August 18-20 Reston, VA
2-Day Agile Requirements Course
August 25-26 Orlando, FL