As an executive, you will be faced with the choice to do the pivot (if you can) or persevere (if you have no other choice). This will lead to a series of “bets”. You lead with a hypothesis that the things you change will allow you to operate at pre-event levels. But, how long will it actually take for you to validate your hypothesis and have a bet pay off with pre-event levels? If you run out of time to figure it out or run out of bets you can place, then you either lose your standing in the market or worse risk going out of business.
Regardless of the organization or institution, there will always be dependencies. The larger the organization, the greater chance of the existence of dependencies.
This template is available for download from Tableau Public
I keep getting asked, does Jira Align support Flow Metrics, as defined in the Flow Framework and SAFe? The short answer is yes. If you believe these metrics will help unlock the potential of your teams, use this community post to see working examples of Tableau reports I have created using Jira Align and Enterprise Insights.
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.
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
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
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.
Emotional Intelligence from ACP
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
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.
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
User Story
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.
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
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.
