Best quote of Agile 2013 award goes to Dennis Stevens of LeadingAgile. In a well received session by Dennis and Mike Cottmeyer, they discussed the topic of gaining support for a sustainable Agile transformation. [follow the link to the presentation]. When fielding a question about taking a culture first approach, Dennis responded:
What are your thoughts? Culture first or last?
PMI Puerto Rico Simposio Anual
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
Agile 101 – Presented at the PM Symposium
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.
Agile101 - What Agile Is and What Agile Is Not
from
Thank you VersionOne for the content for two of the slides.
Agile on Non-Software Projects
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
Agile or Waterfall (Podcast)
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.
New PMI-ACP Classes Announced
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.
Contact Hours/PDUs:
21
CEUs:
2.1
Public or Private:
Both
Duration:
3 Days - 9:00 am to 4:30 pm
DATE
LOCATION
EARLY BIRD
PRICE
August 20-22
Tampa, FL
$1395.00
$1695.00
Register
September 10-12
Reston, VA
$1395.00
$1695.00
Register
October
Atlanta, GA
$1395.00
$1695.00
Register
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.
Operating Outside Your Comfort Zone
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
What is Fist of Five?
Why
It doesn't matter if I'm teaching a class or coaching a team. When the moment comes, I need a quick way for a team to come to a decision. Why should the team decide and not me? From the seven standard leadership styles, I see consensus as the most appropriate for an empowered team. If the team is not empowered, they are not an Agile team.
How
When a decision has to be made, ask the team to do a fist of five. All the team members raise one hand to vote with their five fingers (unless they've suffered an accident in shop class). I depicted in the Fist of Five Pictofigo drawing, member votes range from a fist to five fingers. The term fist to five and fist of five are interchangeable.
Explaining the Details
I see a fist as a blocker. This individual is in complete disagreement and further discussion is required.
One finger (preferably not the middle one) has minimal support to the request at hand. Again, discussion is required.
Two fingers. Not happy with the current proposal. Should discuss as a group to try and resolve disagreements.
Three fingers. Luke warm response. May go along if the rest of the group is voting three, four, or five.
Four fingers. Pretty much agree with the request. There is some apprehension but you can't expect everyone to be all in all the time.
Five fingers. Full support. They drank the Kool-Aid
Certainly, the success of this strategy is going to depend on the team employing it. There will be some who just like to hear themselves talk and will throw up a fist, one, or two every time. Hear them out! You'll also have those who don't like to commit to anything. They will generally put up three fingers. Whatever the outcomes, try to keep a strict timebox for discussions. Remember, this was to be a quick way for a team to come to a decision.
I would be curious to hear when you use fist of five, your successes, and your failures.
Image Source: Pictofigo