I am happy to report that I have just joined the family at LeadingAgile.  LeadingAgile is dedicated to solving the challenges associated with Agile in larger, more complex enterprises. They provide Agile training and coaching, strategic enterprise Agile transformation consulting, and Agile project and portfolio management services.

I’ve known Mike Cottmeyer since LeadingAgile was his blog, he was at VersionOne, and I was at the National Archives.

LeadingAgile is growing and I’m going to help them stand up Agile training around the Southeast and apply my enterprise Agile coaching abilities to some of the larger client engagements.

This is going to be a very easy transition for me.  The Agile community provides opportunities to know a lot of great people.  Step that up a notch to include someone you trust, respect, and enjoy hanging out with, and you’ve got Mike.  Come share a cup of coffee or a glass of beer with us at Agile 2012.  We’ll be there!

Here are some LeadingAgile links to check out:

Website and Blog
Facebook
LinkedIn
Twitter

Mike Cottmeyer on Twitter
Dennis Stevens on Twitter

Related posts:

1. Blending Scrum and Kanban
2. New PMI-ACP Classes Announced
3. Mike Cottmeyer talks about scaling Scrum
4. Thank You Guys and Agile Community of Practice
5. Filthy Fishbowl

Last week, I facilitated an Agile game, with the goal to increase product delivery throughput.  At the beginning of each iteration, I would remind the team “The seven rules of the game are…“.  Upon completion of the third iteration and only seeing modest gains, one of the team members questioned the need for one of the rules and proposed a change in the delivery process.  She asked me, “Is it ok if we do that?”  My response didn’t give her much solace.  Though I knew she was concerned with potentially lowering delivery throughput, I said “it’s easier to ask forgiveness than it is to get permission. Just do it.”  The team then changed their process, resulting in a dramatic increase in delivery throughput.

Though I know success isn’t always the outcome, if you don’t go outside your comfort zone and do something different, you’re never going to see dramatic results.  This applies on both organizational and personal levels.  Within the game, I allowed the team to pilot the new processes so they would either fail quickly or prove their theories.  Over the course of a few iterations, they figured out what worked and what did not, while adhering (directly and indirectly) to the original seven rules.

Within an organization, I recognize things can be much more complicated.  We have regulatory compliance, mandates, and policies to contend with.  I do challenge you to question if they all apply to your current situation.  As with the game, the team just assumed if the rule was listed then it must apply to them.  Without questioning the rules, the results are heavy and burdensome processes.

On a personal level, we litter our lives with artificial constraints.  We accumulate a lifetime of unnecessary rules, rarely stopping to ask ourselves why we do things that prevent us from excelling in the areas we desire.  I’m not promoting living or working recklessly or unethically. Uphold a few guiding principles and reteach yourself to intentionally go outside your comfort zone.  Stop asking permission and let the magic happen.

You can also read this post at LeadingAgile

Related posts:

1. My Own Agile Game
2. Agile and American Football
3. Why the game of Candy Land bothers me
4. Organizing Around Teams
5. Rules of Common Courtesy

I am happy to report that LeadingAgile is ramping up its Public Training Program.  We will now offer regularly scheduled public training classes in the Southeast and Mid-Atlantic.  Early bird registration (30 days or more before class start date) will be heavily rewarded, by way of a $300 discount.  The first class to be announced is the PMI Agile Certified Practitioner.

For those unfamiliar with LeadingAgile, though all of us offer training, we’re all actually Agile practitioners by trade, with years of real-world experience.  We come from a variety of backgrounds, allowing us to offer relevant training specific to the needs of the individual student. Both our public and private classes move at a steady but relaxing pace, delivering the right combination of applicable information, Q&A, and interactive exercises.

When it’s time for your respective exam, you will pass because you understand the concepts, not because you memorized questions and answers. When you go back to your organizations, you will have the confidence of knowing that you understand the fundamentals and how to apply then.

Why Us?

There are a lot of companies out there who offer training but do so from an ivory tower.  The trainers aren’t actual practitioners so they aren’t going to be able to answer your questions based on their experiences.  When it comes to knowledge about the PMI-ACP content, no company comes close to LeadingAgile.  Both Mike and Dennis were on the ACP Steering Committee and I was an Independent Reviewer.  After the exam pilot phase concluded, I transitioned to a new role as Co-Lead of the PMI-ACP Support Team at the PMI Agile Community of Practice.

Who Should Attend

Certainly, if you’re interested in getting the PMI-ACP certification, you should take this class. But, it doesn’t matter if you’re an executive, traditional project manager, or a member of a team.  This class is going to give you a lot of value.  In a typical workshop, I’ve seen anyone from a CTO to an Extreme Programmer to a Tester.  Come with an open mind and you’ll see how we’re on the bleeding edge of Agile thought leadership.

Class Materials

Attendees will receive a complementary copy of the class training material, ACP practice exam, and ACP flashcards.

Course Content

Though this course was originally designed to be an exam prep course, it was enhanced to be an introduction into the principles, values, and practices of Scrum, Lean, Kanban, and Extreme Programming. Our course is developed around a fun 3-day exercise, simulation, and game driven curriculum that encourages signifiant interaction amongst everyone participating in the course. Topics include:

• Understand the Agile Manifesto Values and Principles
• Have an end-to-end understanding of Scrum, its key roles, artifacts, and meetings
• Understand what are and why we use big visible charts or information radiators
• Understand Scrum from a ScrumMaster, Product Owner, and empowered Team perspectives
• Know and understand the XP (Extreme Programming) roles and who does what
• Understand Test Driven Development. Know how it works and why it’s valuable
• Understand Continuous Integration. Know how it works and why it’s valuable
• Understand the Lean Software Development Principles
• Know what Lean Portfolio Management is and how your organization could benefit from it
• Understand what Value Stream Mapping is and how to do it
• Understand the basics of Kanban, WIP, and why it works
• Know how to write and identify good User Stories
• Know what Personas are and how to use them
• Understand what makes a Servant Leader and what they do
• Understand Velocity and its usefulness
• Know Agile Estimation techniques
• Know facilitation methods
• Understand how Agile deals with risks
• Understand the Definition of “Ready” and “Done”
• …much more…

Private Training

If you are interested in private training for your organization or team, please contact us for more information.

Related posts:

1. CSM & PMI Agile Certification Eligibility
2. New Show Announced on ThisWeekIn Network #TWiCCourtesy
3. PMI-ACP Prep Workshop
4. My PMI-ACP Exam Experience
5. Joined LeadingAgile

Back in late 2010, I was features on the Talking Work podcast. Then in early 2011, I appeared at the WorkOut 2011 conference.  Because Ty Kiisel and Raechel Logan were such gracious hosts each time, I couldn’t help but say yes when they recently asked me to make another appearance.  Hear what I have to say, when Ty asks me, “Which is better, Agile or Waterfall?”

I love being asked a provocative question and then given full liberty to articulate what I really think.  All too often, people already have their own set of beliefs on a topic. They’re polite, but only to a point.  They aren’t listening. They’re waiting to talk.  Thankfully, Ty and Raechel are good listeners.

Related posts:

1. The Pepsi Challenge of Waterfall, Agile, or Kanban
2. Waterfall Zombie vs. Agile Zombie
3. Just One Agile Thing
4. Agile Traffic Analogy
5. The Day of The Keynote

This morning, I tried to explain a very important concept to my son. I filled a glass with water to the half-way point. I then asked him if the glass was half empty or half full.

This all came about because he was playing a video game. He placed fourth out of ten and the message better luck next time! appeared on the screen. I could hear him from the other room. That’s so rude!

I asked him what the problem was and he read the message with a negative tone. I corrected him and said people misunderstand stuff like this all of the time. This is why we talk with each other, I explained. If you can’t confirm what they meant, you need to assume they meant it in a positive way. Games are rarely sarcastic.

I know there are people out there who will always be looking for the cloud in the silver lining.
Don’t be one of them.

Image Source: Pictofigo

No related posts.

Regardless of the client I work with, the teams seem to initially struggle with understanding how big (or small) a User Story is, relative to Epics, Features, and Tasks.  It doesn’t help when they first ask how big user stories are and my first response is “it depends“.

It’s not uncommon to find team members asking if they can call smaller stories a minor or sub-story or a larger story a major story.  But then they get distracted by colors of index cards or some ancillary attribute.

The Distinction

Those who identify what the business wants (you may call him or her a Product Owner) take a stab at breaking down stuff to manageable chunks.  You can call those chucks an A/B-level requirement, epic, theme, feature, or spike. It doesn’t matter what you call it.  But when the team estimates that stuff, it is still sometimes (more often than not) too big to fit into a sprint or iteration or just isn’t ready to be worked.

We need to label [this] to set it appart as work that will be committed to next.  Either it will be scheduled in an upcoming sprint or it will be pulled to the next step on a Kanban.  To be clear, I’m not saying the team should start working on [this], merely because they think it is small enough to be completed within a predetermined cycle.  Until your team has sufficiently defined and mapped requirements, developed acceptance criteria, and removed all known blocking dependencies, it is still not a Qualified User Story.

Though I still use the term User Story as that placeholder for conversations, I believe the Qualified User Story more appropriately identifies a placeholder for conversations that meets a definition of ready and allows the team to commit to complete something within an estimated period of time.

Image Source: Pictofigo
HT: Originally posted at LeadingAgile

Related posts:

1. Epics, User Stories and Tasks
2. ALN Arin Sime and User Stories
3. Defining Organizational Structure
4. See Dick See Dick the PM Run
5. The Story of Monte Carlo

This last weekend, I had an interesting exchange on the PMIWDC LinkedIn Group discussions board.  This healthy exchange of viewpoints came about from the following message:

In June, PMPs numbers are down by over 4000 while the PMI Agile certification numbers are on a steady rise. What is preventing the ACP from really getting traction?  http://ow.ly/i/NRLD [link to graphic showing the upward trend of the PMI-ACP]

Because that LinkedIn group is not public, I won’t include the persons name.  Rather, I will refer to him as “Mr. PMP, CSM, ITIL” and include his responses in red.  Even if I don’t agree with everything he writes, I have to respect a differing viewpoint.

PMP numbers likely vary slightly throughout the year and 4,000 is less than 1%. Plus, in the current economy, I don’t think a drop is surprising at all.

Now about PMI-ACP. In my opinion, the PMI-ACP has no market (no one asks for it and, as you note, no one is really seeking it even after PMI lowered qualifying standards to get it). It is simply a me-too certificate competing with already established certifications by Scrum.org and ScrumAlliance.org. Besides, it is mislabeled as Agile when all it talks about is Scrum without ever using the word Scrum–making it even less distinguishable.

Personally, I’d rather see PMI focus its efforts on strengthening the PMP, and the overall body of project management knowledge and practice, than chasing after the latest fads.

[Mr. PMP, CSM, ITIL], interesting opinions. I always find these “corrections” compelling. Everyone can read the August edition of PMI Today (the source of my numbers) and draw their own conclusions. It could be there were 4000 people who really weren’t project managers in the first place, thinking they needed a PMP, and then realized they really did not. We’ll never know for sure.

As for the PMI-ACP, the qualifying standards were corrected while the certification was still in pilot. I know this because I was in Miami with PMI when it happened. It just took several months to get the change implemented in the application process. At least there is a qualifying standard. You and I both have a CSM, yet we both know there is no qualifying standard for that.

The PMI-ACP is not all about Scrum. Again, I know this because I helped create the ACP and because I am the Co-Lead of the ACP support team at the PMI Agile CoP. I won’t disagree that a large percentage of the ACP is Scrum related but in VersionOne’s latest State of Agile survey, a majority of Agile practitioners are using Scrum to deliver value to their respective organizations. I think the certification is pretty representative of contemporary Agile practices.

If you’d rather PMI focus its efforts on strengthening the PMP, I’m curious how you will feel about the upcoming PMBOK Guide revision and Software Extension. Both include Agile knowledge and practices. Does that mean PMI is chasing after the latest fad or is it evolving?

Derek, I’ll admit the 5th edition draft PMBOK is troubling–almost as if some folks are trying to sabotage the PMBOK or simply making changes for the sake of changes. Don’t get me wrong, I am not against change but some of what is occuring is not good, doesn’t fix some problems in the 4th Edition and introduces some new contradictions and confusion. Waiting to see what the final release settles on. 

Stats can be fun and too often misleading. I don’t think month-to-month changes in active certificate holders is very meaningful and PMI-ACP’s less than six month track record is nonetheless too short. It’s 7 to 18% month-to-month increases are already faltering, losing 32% of it’s growth rate in the latest month. During this same time, PMPs dropped just under 1%. If both of these two latest trends continue, PMI-ACP will max out around 6,923 and reach parity (with current month declining) PMP in just over 38 years. 

As a reality check, PMP and CAPM make up 99.2031% of PMI’s certificate holders. I suspect the overall number of ‘traditional’ projects is a not too dissimilar ratio. Adding in the few thousand CSM and other certificate holders won’t significantly shift this ratio. And traditional project management is, if practiced well, agile and not the caricature painted by Agile and Scrum advocates.

Listening to people who are participating in the PMBOK revisions sounds a lot like legislation in the government. In the beginning, a bill with a bold new idea or fix is presented. In order to close the deal, the bill gets watered down and new stuff that really has nothing to do with the original bill gets introduced. I can totally see that happening with the PMBOK. But I do think common agile concepts and practices should be included. The question is, will it be a square peg in a round whole, based on the format of the PMBOK?

Speaking to the certification stats, I once presented a correlation graph claiming an increase in ice cream sales caused deaths by drowning. It was merely illustrating that metrics can be used to support just about any claim. If PMI gets more market penetration in India and South America, I think the overall growth rate for the PMP (and ACP) will continue. With PMI being the marketing machine that it is, I see the ACP cannibalizing market share from ScrumAlliance and Scrum.org, not from the PMP.  Only time will tell.

It’s my belief that “Agile” practices will be accepted as “Traditional” practices over time. Until then, the misinformed will believe it is a silver bullet. It’s funny, when I coach new clients, I always have at least one project manager tell me that he or she proposed similar changes to leadership but was ignored. I’ve also had attendees of my training tell me that having PMI offer an “Agile” certification legitimizes it as a possible delivery mechanism. This isn’t new stuff! Whatever gets people talking works for me.

HT: Project Management Institute

HT: VersionOne

Related posts:

1. Official PMI-ACP Numbers
2. My PMI-ACP Exam Experience
3. Chasing the Carrot
4. CSM & PMI Agile Certification Eligibility
5. How to Claim PMP PDUs as a Non-PMI Member

Well, the wait is finally over. My paper, “Traffic Lights to Burndowns, an introduction to Visual Management Systems” was selected for presentation at the PMI Global Congress being held in Vancouver, British Columbia in October.  Now all I have to do is respond to this letter by Friday and fill out yet even more paperwork.

Related posts:

1. Speaking at AgileDC 2011
2. My Next Speaking Gig
3. PMI-ACP Prep Workshop

I was updating my Agile Certified Practitioner (ACP) Training slide on Emotional Intelligence and thought of the relationship it has with our humanity.  A few clicks later, I found myself reading a passage on Wikipedia on “the virtue of humanity”

The three strengths associated with humanity are love, kindness, and social intelligence. Humanity differs from justice in that there is a level of altruism towards individuals included in humanity more so than the fairness found in justice. That is, humanity, and the acts of love, altruism, and social intelligence are typically person to person strengths while fairness is generally expanded to all.

To me, social intelligence is nothing more than social competencies of emotional intelligence. We need empathy and we need social skills.  I’m left conflicted from the Wikipedia passage where it says humanity and justice differ.  Fairness should be found in both social and individual competencies.  It just doesn’t have to be explicitly stated. 

Image Source: LeadingAgile PMI-ACP Training

Related posts:

1. How David Bland helped my PMI ACP workshop
2. Becoming a PMI R.E.P.
3. New PMI-ACP Classes Announced
4. PMI-ACP Numbers So Far
5. Mapping the PMI-ACP Exam

Regardless of where I coach or teach, there is always someone who approaches me and says something like, “Agile is great for software projects but what about projects that aren’t software related?”  When asked the question, I usually give examples like a U.S. Marine fire team or air crew or a home construction site. (I’ll save those stories for another time).  I now have a new story to tell about a cross-functional, highly collaborative team, which competed for the Progressive Insurance Automotive X Prize.

While I was at Agile 2012, I met Joe Justice of Team WIKISPEED and had a chance to actually touch a car that was designed and built using Agile methods. (see cool photo enclosed)

Here is some back story from a 2011 press release:   Based in Seattle and led by Joe Justice, WIKISPEED is a collaborative team of over 50 experts and volunteers dedicated to offering ultra-efficient, ultra low-cost, mass-production road-legal vehicles. In 2010 the team’s SGT01 prototype placed in the top 10 in their class out of 136 cars overall in the Progressive Insurance Automotive X Prize.

Joe was able to build his first functional prototype in just three months.  The car that competed in the X Prize got 114 MPG (Highway). Compare that to the Toyota Prius which currently gets 51 MPG (Highway) and was introduced in 1995.  The reason auto manufacturers are so slow to “better” their products is because change is very expensive for them.  It is not uncommon for auto manufacturers to operate on 10 to 25 year development cycles.  Before Object-oriented programming methods were introduced, software teams used to operate much the same way.

By modularizing how we build software, we’re able to shorten our development cycles down to days.  By shortening our development cycles down to days, we give ourselves the opportunity to get feedback from our customers and create things that they really want, not things that we think they want.  We save ourselves and our organizations countless dollars in wasted development, due to waiting too long to get feedback from our customers or by operating in functional silos.  My breaking our teams down into small, cross-functional, empowered teams, we shorted feedback cycles as much as we can.

Being Joe is a client facing software consultant, building Agile teams and practices, why would he limit the benefits of Agile to just his customers?  Joe and his team have a car that has a development cycle of seven days.  They do this by modularizing the car.  They can switch the gasoline engine to an electric one in about the same time it takes to change a tire. They could change the car body from a convertible to a pickup truck.  All of this allows them to make changes and develop quickly.

The car is safe (passes road safety standards), because Team WIKISPEED developed safety tests before building the actual parts.  This helps them lower waste (Lean).  Next time you say you can’t afford to do test-driven development, think about that.  They do all of their work in pairs, avoiding time training that is not productive. (XP Practices) Again, the next time you say you cannot afford to pair people, think about that.  Pairing also helps lower the need for most types of documentation.  If everyone has a shared understanding, you have less need for it.  They visualize their workflow to help identify hidden delays and deliver something every seven days (Scrum).

So, do you still think Agile is only for software projects?  The fact that they use 7 days sprints on hardware, when I hear people say they can’t do anything less than 30-days on software, just goes to show you where there is the will there is a way.

Check out Joe’s session from TEDxRainier

Post originally appeared at LeadingAgile

Related posts:

1. Waste In Software Projects
2. Technical Debt
3. Agile and American Football
4. The Agile Introduction
5. Using Agile does not mean a lack of defined process

Regardless of your organization and goals, everyone is trying to do things better.  I commonly hear about management asking its people to do more faster, often with less.

One major mistake I see time and time again are organizations trying to do things faster before really understanding their own processes.  If you don’t stop and really ask yourself if you’ve optimized the whole of your processes, before trying to go faster, any successes will be short lived.  I can assure you that speed without optimization is not sustainable.

Recently, I got back into running.  I haven’t ran consistently for a few years and honestly, I always hated it.  The goal was never to run a half or full marathon.  The goal was always to stay under 28 minutes for 3 miles.  That was the minimum speed requirement on a Marine Corps PFT back in the late 80′s, when I was enlisted.  Without fail, my feet and knees always hurt.  So, I did what any novice runner would do. I bought really cushioned running shoes.  I was able to run a couple miles at a time, at the pace I wanted, but I had to stop due to sharp pain in my knee and lower back.

A few weeks ago, I had lunch with a friend who is also a former Marine but he does a lot of distance running.  His goals include running half and full marathons.  I told him of my pains and he said I needed to read the book Born to Run and consider barefoot running.  Now, barefoot running includes both running barefoot or wearing minimal footwear.  Remember, the modern running shoe wasn’t invented until the 1970′s.  By getting rid of my cushy shoes and changing how my feet strike the ground, suddenly the pain is gone.  It was that simple.  A few days ago, I ran five miles and I could have kept going.  Suddenly, three miles in 28 minutes is no longer the goal.  Because I have a stable velocity with no pain, I now have a sustainable pace.  I know I can now go the distance.

Think about your organization again.  Do you meet your commitments, but it’s painful?  Do you sometimes not meet your commitments, because your pace is not predictable or it’s just too fast?  Stop and think about what you’re doing.  Really take a fresh look at how you’re doing things and consider making some changes.  Don’t use the excuse of “this is just how we’ve done it in the past”.  Once you find and address the root causes of your pains, you can refocus on what you’re trying to accomplish and reaching both those short and long term goals.

The picture above is of me in a LeadingAgile running shirt.  Thank you Mike Cottmeyer for the slogan (and the shirt).  This blog post was originally posted on the LeadingAgile blog

Related posts:

1. Reading about Process Improvement
2. Process Improvement and Grilling Steak
3. Did you learn your lesson?
4. We didn’t learn our lesson
5. Why Ask Why

I want to thank everyone for coming out to the PMI Washington D.C. Project Management Symposium. It was a great crowd. The ballroom was full and I was told there were up to 400 people in the room for my talk. As promised, here is the SlideShare of my presentation.  If you go to the SlideShare site, you have the ability to download it.

Thank you VersionOne for the content for two of the slides.

The post Agile 101 – Presented at the PM Symposium appeared first on The Critical Path by Derek Huether.

There isn’t a week that goes by that I don’t hear some awesome quote or analogy.  I put as many as I can into my mental back pocket, hoping for an opportunity to pull one out at a moments notice.  When you’re stuck for a quote or analogy, to help someone understand what you’re trying to say, do you ever ask yourself what’s that awesome quote that I just heard the other day?

Here are 10 that I keep handy.  Are there any quotes you would like to share?  Please add them to the comments section.

• Because the needs of the one… outweigh the needs of the many. – Star Trek III: The Search for Spock, Captain Kirk.  I like to use this quote when explaining the contrast between egoism, utilitarianism, and altruism (servant-leadership).
• The more they overthink the plumbing, the easier it is to stop up the drain. – Star Trek III: The Search for Spock, Scotty. I’m admittedly a Star Trek geek.  I’ve used this once when trying to articulate Lean thinking.  I also segway into the untrue but compelling story of the Million Dollar Space Pen.
• The thing is, Bob, it’s not that I’m lazy, it’s that I just don’t care. – Office Space, Peter Gibbons.  I like to use Office Space quotes, particularly when referring to empowered teams and while drinking from my Initech coffee cup.  Mmm’kay? Greeeeat.
• Luck is not a factor. Hope is not a strategy. Fear is not an option. - James Cameron.  This quote was on the back of the LeadingAgile t-shirts we all wore at Agile 2012.  I still have strangers walk up to me and ask about its origin.
• That which does not kill us makes us stronger. - Friedrich Nietzsche.  I think of this quote during almost every run I take.  After taking an inventory as to my physical condition, I have a mental debate as to stopping or keep pushing forward. I keep pushing forward.
• We keep moving forward, opening new doors, and doing new things, because we’re curious and curiosity keeps leading us down new paths.- Walt Disney.  I’ve told my son over and over again to challenge the status quo (I don’t call it the status quo because he’s seven) and when given the choice, try new things.
• When we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right. - Walt Disney  The power of positive thinking and an empowered team.
• Plans are of little importance, but planning is essential – Winston Churchill.  Another almost identical quote came from Dwight D. Eisenhower: Plans are worthless, but planning is everything When I talk about the Agile Manifesto and how we should be responding to change over following a plan, this becomes one of my most commonly used quotes.
• Stable Velocity. Sustainable Pace - Mike Cottmeyer.  This quote appears on the back of the LeadingAgile running shirt. It has become the unofficial motto of my life, as it applies to work, family, and running
• We don’t need an accurate document, we need a shared understanding - Jeff Patton. I was attending Jeff’s session at Agile 2012, when I heard him say this.  It really resonated with me.  I don’t know if the quote was scripted or impromptu.  Regardless, when I recently quoted him at a Project Managment Symposium in Washington DC, I saw over 400 project managers nodding their heads.

This post was originally published on LeadingAgile

The post Favorite Project Management Quotes appeared first on The Critical Path by Derek Huether.

I am back from the PMI Global Congress in Vancouver, British Columbia.

My lack of fancy pants went pretty much unnoticed.  I brought plenty of energy (and coffee) to my session and it appears people were very happy with the results.  I was referred to, at one point, as the Energizer Bunny and even the PMI quoted me.

I definitely left people wanting more.  It was an introductory talk and I only had 1:15 to present.  With 20 minutes dedicated to people in the audience working together to create their own Visual Control Systems, I found myself all over the room and loving every second of it.

It was great to meet people I’ve known for several years via the blog and through the PMI Agile Community of Practice.  It was also great to meet so many new people excited about Agile becoming more mainstream.

Side note: If you saw me limping during my session and at the Congress, it was because I may have a fractured heel.  I guess my OJ Simpson run through the airport to make my flight did it.

The post PMI Global Congress Presentation on VMS appeared first on The Critical Path by Derek Huether.

As Hurricane Sandy approaches the East Coast, we’re already feeling its impact.  You can’t find batteries, milk, toilet paper, or bread anywhere. The only thing I went out looking for yesterday was coffee.  Strangely enough, I didn’t have to fight anyone for it. It was interesting to watch people and see how they handled the stress of the situation.

What I find even more interesting is how leaders are handling all of this.  By title alone, they should lead, right?  I see this as an opportunity for us to distinguish the wheat from the chaff.  Some leaders are doing just what they should. They are leading.  They are establishing states of emergency, they are closing schools, and shutting down public transportation.  Others are just waiting to see what others are going to do.  Though I am a strong proponent of waiting to make a decision until the last responsible moment, it feels like that moment has passed.  Has your leader stepped up?

I’m curious how this weather event is going to impact local elections.  I’m not referring to people not having electricity.  Hopefully, we’ll all be on the mends by next week. No, I think Hurricane Sandy is bringing attention to where there is leadership and where there is a lack of it.

Image Source: Weather.com

The post Demonstrating Leadership appeared first on The Critical Path by Derek Huether.

Imagine barely missing the Nor’easter up in Connecticut, only to land in sunny San Juan, Puerto Rico 24 hours later for the PMI Puerto Rico Simposio Anual. That was me last week. My time in Puerto Rico was short but I met some amazing people and had a great time.  I spent one day offering a seminar on Agile Project Management and one day as a Simposium Speaker.  There was a lot of interest around Agile and what it is (and what it is not).  It was exciting to have the opportunity to interact with a completely different group of people, not focused on U.S. Government related work.  Just to confirm, not everyone is Washington D.C. is, but I would argue a large group I spoke to last month at the Washington DC PM Symposium were.  The people I spoke with this last week were entrepreneurs, company presidents, and managers…  What I found as the common thread was not on keeping a schedule or staying on budget.  It was about satisfying customers, maximizing ROI, and responding to constant change.  Regardless of the language barrier on my side, they could understand what I was talking about, confirmed by the nodding heads and mouthed “sí.”

I want to thank PMI Puerto Rico for being such amazing hosts.  There is something very notable I want to point out about their symposium.  Much like the symposium attendees, the organizers’ primary concern appeared to not be keeping the symposium on a tight schedule.  The focus was ensuring the people attending got as much value as they could provide in the time they had.

Originally published on LeadingAgile

The post PMI Puerto Rico Simposio Anual appeared first on The Critical Path by Derek Huether.

A while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want?

In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you’ve been doing Scrum for a while. It doesn’t talk about things that happen leading up to your team’s first Sprint.  It doesn’t talk about the complexity of scaling to the enterprise.  It’s just vanilla.

I just got back from coaching a new team and I’ll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That’s where things started to get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we don’t know much.

The purpose of the Sprint Planning 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.

You’re new to Scrum.  You don’t have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

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. 

Again, you’re new to Scrum.  How do you know what small enough is?

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).

Again, you’re new to Scrum.  You have no historical data.

Determining Velocity

The velocity of a team is derived by summing the 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.

If you have a new team, not only do you not have a velocity, you won’t have any completed work to compare your estimates to and you won’t know how many deliverables to commit to.  What do you do?  I think you just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned to do; Act on what you discover.

The post New Scrum Team Challenges appeared first on The Critical Path by Derek Huether.

The more I travel, the more I find myself observing how business travel (particularly flying) is a lot like application development. The flow of travelers (business value) are processed through a system much like ideas flow from inception to delivery.  When reviewing the processes of  the business traveler (delivery), I keep asking myself why the system has so much room for improvement and why we as participants within it don’t fix it.  I notice many travelers do few things that provide direct value (save time).  Rather, we do things that either provide little or no value but are necessary or are just wasteful.

As a business traveler,
I want to arrive to a destination as quickly as possible
without violating identified constraints.

Constraints: Quality and Cost 

Quality (safety thresholds):

We want to make sure that some knucklehead does not get on a plane and do something destructive.  Rather than quality, the FAA calls this security.  In the end, the underwear bomber who unsuccessfully detonated his skivvies mid-flight is like discovering a severity one bug in Production.  It would have been a lot cheaper, if this guy was stopped at a security checkpoint and prevented from getting on the plane in the first place.  As a result, I have Bubba the TSA Agent measuring me for a pair of pants every time I opt out the body scan. Do these theatrics actually increase quality?  I’m not sure. But I digress. [TSA Removing Body Scanners?]

We want to ensure planes don’t fall out of the sky, due to mechanical issues.  In an attempt to ensure we don’t go below this quality threshold, the FAA requires airlines to conduct regularly scheduled maintenance on aircraft.  As stakeholders, both the airlines and passengers see maintenance translate as on-time departures.  As this relates to application development, customers don’t always think (or care) about code refactoring, fixing bugs, or paying down technical debt.  Still, if they don’t want the system to crash or have a delayed launch, this out-of-site process has to take place on a regular basis.

Cost (budget thresholds):

As a business traveler, I expect my costs to fluctuate, based on quality and the speed in which I move through the system.  If I want to move through parts of the system faster, I can pay more.  In the end, local optimization just makes the process seem less painful.  It is, until you get to the next step or stage of the process.

The overall system:

1. I arrive at the airport (park in the Daily garage) [every 15 minutes a shuttle arrives]
2. I stand in line at the security (TSA) checkpoint.   [1-30 minutes]
3. I am given the choice of x-ray or full body scan [pay more for express search] [1-20 minutes]
4. I opt out? [doesn't necessarily increase quality] [5-10 minutes]
5. I arrive at gate and
6. Board flight by “zone”  1st Class, Zone 1, 2, 3 [0-20 minutes]
7. Fly to destination [varies]
8. Land at destination and disembark the aircraft [5-15 minutes]

Though you can have several local optimums within the system, like any process we need to look at optimizing the system as a whole.

Look for bottlenecks and address them.  If there is a lead time between the start of one of the eight processes listed above and its execution (completion), there is a bottleneck.   A lead time is the latency (delay) between the initiation and execution of a process. For example, the lead time between getting into the security (TSA) checkpoint line (process step 2) may be anywhere from 1 to 30 minutes. In industry, lead time reduction is an important part of lean manufacturing.  In application development, it allows us to shorten our iterations or feedback loops.  In travel, it allows us to get on with our lives with less impact to events happening outside the system.

One way I’ve seen people shorten the lead time at this process step is to just be ready.   Sounds obvious but you would be surprised.  There are signs and videos leading up to the security area.  TSA instructs you to have your boarding pass and photo identification ready.  They inform you what is allowed and what is not allowed (step 3).  I’ve seen countless travelers wait until they are at the podium before digging through purse or pocket, only to have a minor panic attack because they can’t find a drivers license.

I’ve seen the same thing with application development.  Teams don’t have their work ready and then there are delays in getting it done.

The post Value Stream for Business Travelers appeared first on The Critical Path by Derek Huether.

The proclamation by Marissa Mayer last month, informing Yahoo employees that working from home is no longer an option, really seemed to bring an important conversation front and center.

The memo that started this firestorm stated in part -

“To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices… We need to be one Yahoo! and that starts with physically being together.”

I’ve worn a lot of hats over the years.  In each instance, there has been a common goal:  Be as successful as possible.  Being “successful” is unique to every situation so that’s why I include ”as possible”.  But when you add happiness to the equation, what does that mean?

If you are in a job where you are rapidly iterating a product and continuously collaborating with others on your team, being face-to-face or side-by-side with your teammates will provide an opportunity to be as successful as possible.  Being collocated is no guarantee for success but being distributed (dislocated) is going to certainly limit your chances.  Leaders should focus actions more on making their companies, projects, or products successful and less on trying to make employees or teammates happy.

Now, don’t get me wrong.  I’m not saying we shouldn’t be empathetic to the needs of others.  I’m just saying there comes a point when you need to look at the costs and the benefits of remote work.  If the team is not realizing its potential, because one or more of them are working remotely (because they want to and not because they have to) we have a misalignment of goals.  Why would they sacrifice potential success for their personal comfort?  Well, businesses are trying to find ways to incentivize their employees. They hope that by incentivizing then, they will be happier and more productive.  But see, that is part of the problem. There is a belief that the incentives will make them happy.  Happiness is one of the byproducts of satisfying work, which can be derived from feelings of mastery, autonomy, and purpose (link to talk by Dan Pink).  I believe (in some cases) the work-from-home incentives will have a negative affect.

When companies hire us, they are NOT hiring us to make people’s lives better.  They are hiring us because there is value locked up in these companies and they are unable to produce.  They are hiring us to help them unlock that value.  Period.

What’s one of the first things I would propose if I coached teams at Yahoo? Bring the team together, face-to-face or side-by-side.  The only thing I disagree with in the Yahoo memo experpt  is where it states “…we are all present in our offices…”  I propose they get out of the private offices and into a team space.

Balanced piece about the pros and cons of working at home on Fast Company

Image Credit: Pictofigo

The post My Perspective on Remote Work appeared first on The Critical Path by Derek Huether.

As recently as this week, I’ve been involved in conversations with customers about how we can help make their teams deliver more predictably.  How can they meet commitments on all levels of the organization, including project, program, and portfolio?

Well, it’s not easy.  There is no silver bullet that is going to allow you to align the organization overnight.  I do, however, have one recommendation:  Stop trying to maximize the utilization of your people.  I know some are going to find that hard to understand.  To maximize value throughput, you need to keep your people as busy as possible, right?  Didn’t Henry Ford do it that way, when he had cars coming off the assembly line at three-minute intervals?  Actually, no, he did not.  What he had and what you need is a balanced system.

Henry Ford did not have everyone working at 100% utilization.  If everyone worked at 100%, the result would have been congestion — bottlenecks within his (assembly) system and the production of excessive parts inventory.  Instead, one of the many things he did was focus on limiting lead times.  That’s the time something waits before an activity happens.  By understanding his system, he was able to have the right amount of people, working at the right pace, in the right sequence, in order to maximize flow (delivery through the system).

When trying to get your teams to delivery predictably at your organization, let’s look at this from a 100,000 foot view:

• Understand Current and Potential Capability and Capacity
• Understand the Delivery System and Establish Goals
• Balance Capacity and Capability with delivery throughput
• Monitor Performance

That is how you establish predictable outcomes.

No let’s look at this with some detail.

Understand Current and Potential Capability and Capacity

You’ve probably heard the analogy of a freeway being a value delivery system.  If not, let me draw the parallels.  On a freeway, we don’t care about utilization; we care about throughput. That is, we don’t care how many vehicles can fit onto the freeway. We care how quickly we get from point A to point B.  Measuring the capacity of the freeway is not going to directly help us. Measuring the throughput will.  For those who follow Lean Startup, these are referred to as vanity metrics and actionable metrics.

Actionable metrics can lead to informed decisions and subsequent action.  Example, I know how fast the vehicles travel on a given freeway, therefore I can plan accordingly to arrive on time.  Vanity metrics show that you’re measuring things, but they really aren’t helping you. You need to measure the right things.  By measuring the capacity of a freeway and then trying to fully utilize it would be foolish.  Strangely enough, I see organizations do that with their people all the time.  They try to keep them as busy as possible.

Understand the Delivery System and Establish Goals

We don’t build bigger freeways so they can hold more vehicles.  We build bigger freeways because we’re not smart enough to figure out how to limit the size or amount of vehicles on them at the same time.  The fewer or smaller the vehicles on the highway at the same time, the faster everyone moves along.  To increase throughput (speed) on a freeway, you need to increase the ratio of space utilized by a vehicle relative to the total space of the freeway.  If we could increase the (distance) buffers between the vehicles, we’d have fewer start and stops along our commutes. Once we hit higher utilization rates, things dramatically slow down until we have traffic jams.

Balance Capacity and Capability with delivery throughput

It’s the same thing with knowledge based systems!  Exceed a 70% utilization rate and you’ll begin to see dramatic performance decreases.

One thing that I have seen that is bringing it together is enabling teams to make their own commitments.  Once they have a sequenced queue of work and all the people necessary to complete that work, allow them to commit to, start, and then finish it.  You should begin to see the flow of value start to emerge.  Don’t pull people from the team to give them “busy” work.  Don’t push extra work on the team to keep them busy.

Monitor Performance

You can tell if your people are over-utilized by measuring the lead times.  If their work is properly sequenced, and they limit the size and volume of work they agree to do at any given time, the result should be minimal delays.  If you want to go faster, you may have to change the system.  Measure how long it takes to get something through your system.  Reflect on that.  Were there any dependencies on other people or resources that slowed you down?  Did you have your people over-utilized?  Was the work you committed to too big?  Look for an area of possible improvement, address it, and run work through your system again.  Did the lead time get shorter?

Going back to the commuting analogy, for those doing the driving, understand the conditions and know the optimal start time to begin your commute in order to avoid delays and arrive at your destination without breaking any laws.  For those asking for arrival commitments, respect what the driver tells you.  If you don’t, you’ll find people doing things like driving on the shoulder or illegally speeding in the express lane, just to arrive on time.  Sooner or later, there’s going to be an accident.

Originally published on the LeadingAgile blog

The post Getting Teams to Deliver Predictably appeared first on The Critical Path by Derek Huether.