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.
Almost two months ago, I left my gig advising a Federal PMO to join LitheSpeed. LitheSpeed offers premium Scrum and Agile consulting, coaching, and training services. So, what do you do when you win work? Well, you put the word out that you're looking for qualified people! So, are you an Agile coach who would like to be considered for our current and future engagements? Complete the form and you'll be on the list.
Don't see the Google form? Try this link
Drawing by Pictofigo
Sprint planning is a timeboxed working session that lasts roughly 1 hour for every week of a sprint. In sprint planning, the entire team agrees to complete a set of product backlog items. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint.
Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.
Ensure all sprint candidates meet the team’s definition of ready. In the days and weeks leading up to sprint planning, the Product Owner identify the items with the greatest value and works towards getting them to a ready state.
The product backlog can address just about anything, to include new functionality, bugs, and risks. Product backlog items (PBI’s) must be small enough to complete during a sprint and should be small enough to complete within a few days. All stories must be verified that they are implemented to the satisfaction of the Product Owner.
Based on historical data of the team, first determine if product backlog items are too large to complete in a sprint. In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice. Therefore, stories should not be incomplete or process-based as a horizontal slice.
To calculate a commitment, mature teams may use a combination of both team availability and velocity. However, new teams may not know their velocity or they may not be stable enough to use velocity as a basis for sprint planning. In these cases, new teams may need to make forecasts based solely on the their capacity.
First of all, as velocity is unique to every team, never use another team’s velocity to plan your sprint. Derive team velocity by summing the story point estimates of all completed and accepted work from the previous sprint. By tracking team velocity over time, teams will begin to focus less on utilization and consequently more on throughput.
For teams without a stable velocity, each team member should provide three simple measures to determine capacity. First, what are the number of ideal hours in their work day? Second, how many days in the sprint will that person be available? Third, what percentage of time will that person dedicate to this team?
// If your team is new to Scrum, download a copy of the Sprint Planning Cheat Sheet //
Drawings by Pictofigo
As you may know by now, I left my gig advising a Federal PMO to join LitheSpeed as a Senior Manager. LitheSpeed offers premium Agile software development training, coaching and management consulting services. My relationship with the organization actually started several years ago, when I attended ScrumMaster training to earn my certification. (You can't be a Certified ScrumMaster through the Scrum Alliance unless you get your training from a Certified Scrum Trainer®.) Well, the world is evolving and so is LitheSpeed. See, Certified Scrum Trainers (CSTs) play a vital role within the Scrum Alliance. They are the only ones licensed to teach Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) courses. Stringent certification requirements are imposed on CSTs to make certain that only those who are qualified to meet the commitment are entrusted to engage in this role on behalf of the Scrum Alliance.
Well, what about those out there who are members of the Project Management Institute? What about those seeking the upcoming PMI® Agile Certified Practitioner (PMI-ACP)SM certification? If you want to qualify to sit for the PMI-ACP, you will need 21 training hours in an Agile-specific curriculum. To ensure members of the PMI know LitheSpeed offers quality training that will help satisfy that requirement, we applied to and were approved to be a PMI Registered Education Provider (R.E.P.).
What does it take to become a PMI R.E.P.? Applicants must complete a 33-page application, which includes a strict quality review of both the trainers and the curriculum. The first class we submitted and got approved was our Certified ScrumMaster course; next will be our Certified Product Owner and PMI-ACP Prep courses. As an R.E.P., LitheSpeed has been approved by PMI to issue Professional Development Units (PDUs) through the PMI website. Our goal is to equip our trainees with tools they can apply on current and future projects, not just help them qualify to take an exam.
I know this post sound a little like a press release. But, I have to admit, applying to become a PMI R.E.P. is no cakewalk.
If you would be interested in attending one of my upcoming public training sessions or would be interested in me providing a private training session, shoot me an email!
PMI® and the PMI® Registered Education Provider logos are registered trademarks of the Project Management Institute, Inc. PMI-ACP is a service mark of the Project Management Institute, Inc.
This evening I attending the monthly Agile Leadership Network event. I noticed a very familiar slide on Waste In Software Projects. It looks familiar because I have it in my training deck as well! Yes, my Introduction to Agile class has a slide that credits the Standish Group Study reported at XP2002 by Jim Johnson, Chairman. In reviewing software systems, Jim Johnston, Chairman of the Standish Group, determined that in systems defined and delivered using a traditional / waterfall style approach almost half of all features developed and paid for are never used. The question this evening was, for the 45% of the features that were never used, what was the cost incurred? Well, I can tell you it's probably a lot more than 45% of the budget! What if the features that were never used were actually the most costly as well? The rule we should learn here is we should eliminate the waste at the source, before it makes it all the way to the Production environment. If a feature or product is never used, it's waste. But, since XP2002, have we learned our lessons? Are we still delivering features that customers will never use? I figured I would create a quick Google Doc that would collect some data. After giving it some thought, I decided to remove the link to the Google Doc. The collection of data was just a distraction from the actual blog post. Thank you to those to participated.
Ever heard of the cone of uncertainty? The cone shows the historical error at certain time periods in a tropical cyclone forecast. What happens today and what has happened in the past is pretty much all we know. We can certainly use all kinds of scientifically proven processes or models to try to predict the future. But, in the end, we won't know what tomorrow will bring until tomorrow. If you are dealing with machines, you should be able to predict upcoming events with relative certainty. If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none.
We need to assume that baselines may change significantly during a project or in life. In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.
You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins. You do everything you can to lay it all out, attempting to account for every possible variable. Unfortunately, you don’t know what tomorrow will bring. So, the further out the schedule goes, the greater the risk something is going to change. What’s it going to be? Is scope going to change or maybe the schedule will slip? With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.
In reality, you begin with the greatest unknown. Even some of the unknowns aren't even known. Just accept it! You’re not the Amazing Kreskin. You can’t predict the future. The only thing that is guaranteed is something is going to change. So, plan for that change. Know the goal you’re trying to reach. Keep your eye on that goal. Now, do what you do. Develop, lead, manage… it doesn’t matter. What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again. Make some adjustments and repeat. You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.
You can not predict the future, only plan for it. You can not steer a hurricane, only plan for it. You can not prevent change… Can you guess what comes next? That’s right, you plan for it.
Several years ago, I was working with a client who was obsessed with keeping resources (in this case, people) 100 percent utilized. The client boasted that he had a strong matrixed organizational structure and everyone was a member of multiple teams working on multiple projects. When I came on board, I noticed that people were spread extremely thin between the projects. There was a lot of work being performed but very little was getting done. How can you make real progress if you have multiple managers asking you to deliver that high priority something for them? How can you make real progress if you have to constantly shift gears and go in different directions? In theory, having a matrixed organization sounds really great. Resources can potentially be utilized up to 100 percent. In reality, the goal is not utilization of a resource. The goal is throughput and delivering something of value. In the end, having a matrixed organization made people busy but it did not make them more productive. Perhaps managers felt more productive because they essentially had more people to manage. But again let me stress, the goal is not to manage people. The goal is to deliver something of value. When I did my original assessment, there were two common complaints. First, team members didn't know who to take direction from. Two, team members never seemed to have time to just focus on one thing and get it completely done.
Once we got people grouped into several (cross-functional) teams and then collocated in team areas, we actually started making deliveries on projects. The PMI would define this reorganization as being projectized. But, let us not forget that this is about the teams and creating an environment in which they can deliver value.
Organizing around teams allows you to estimate, plan, and deliver at a more accurate level of granularity.
My friend and colleague Sameer Bendre and myself are currently serving as Co-Product Owners for the PMI Community of Practice (CoP) blog. Like any challenge I accept, I like to eat my own dog food. What that means is if we're going to have a blog about Agile, we should take an agile approach to its creation. Though I wouldn't say the following is exclusively Agile, I am listing some content from a Product Owner training deck. There will be three things I guarantee: Transparency, Inspection, Adaptation
Transparency -Honesty about progress & problems Inspection - Feedback will come from real customers & users Adaptation - Tweaking of blog based on feedback & goals
Because we're initiating a project, Sameer and I are going through some discovery. First up is project orientation. We're doing process analysis, we're understanding scope and objectives, and we're creating the initial product backlog.
But, are we ready to start blogging? To do so, we need to ask ourselves Why, What, and How.
Why?
What are the stakeholders’ goals?
What?
What is the Outcome Vision? What is the end result?
How?
What is the Implementation strategy?
Yesterday I heard an awesome quote, as I sat in on a Product Owner class. My colleague Arlen Bankston quoted Peter Skillman.
Enlightened trial-and-error succeeds over the planning of the lone genius
I've never been one to silence that inner voice. If I have a problem, I share it and have faith in the collective minds of my readers to propose a solution. I'm not saying I don't have vision. I do. What I'm talking about here is an impediment or a problem. When I looked at the web address of the Agile CoP blog, I noticed that it was deep in the PMI website. There was no link from the homepage. The Agile CoP blog can only be viewed by (logged in) PMI members. So, the question I have to the CoP members is, how do we get the word out? How do we blog about things that others (outside of our immediate group) will actually read?
My short term solution is to repost here, on the Critical Path blog. The next thing I would propose is someone convince PMI to allow more people to post on the Voices blog. It's the only PMI blog that appears to be open to the world. If PMI wants Agile readers, they need to open the blogs to more readers.
In closing, I'm not lambasting PMI. I'm bringing attention to both an issue and an opportunity. I want more visibility to what our CoP has to say. I want to have our voices be heard.
HT: Pictofigo for the drawing
My family and I recently went to Walt Disney World’s Magic Kingdom and Hollywood Studios. My wife was extra excited because it was going to be "Star Wars" weekend at Hollywood Studios while we were there. Imagine parades filled with Star Wars characters, Storm Troopers and Clone Troopers everywhere...and the force being with us (or maybe not). My wife was very excited when she found out she had a chance to get a picture taken with and get an autograph from Anthony Daniels of C-3PO fame.
This is how it was to go down. When the park opened, a predefined amount of tickets would be given to those people standing in a line. Once those tickets were gone, there were 30 remaining "standby" tickets. There would be two autograph sessions, lasting one hour each. IF Mr. Daniels got through the "guaranteed" group of ticket holders in less than one hour, he would then start to greet the standby ticket holders in the order in which they arrived that morning. We were standby ticket holders #19, #20, and #21 (out of 30). Everyone was required to stand outside in the sun until their ticket number was called. They were then allowed into an air conditioned building to meet C-3PO. When they were done, the "beaming" fan exited the building.
Well, the morning session (in close to 90 degree heat) came and went. The first 10 or so standby ticket holders did get in. We were told to return in the afternoon. Upon returning in the afternoon, the guaranteed group came and went and as we watched the clock tick closer and closer to the one hour mark, they accepted standby after standby. We had convinced ourselves that certainly Mr. Daniels would understand that there were only a few people left in line and would stay the extra 5-10 minutes it would take to greet us and sign a quick autograph. Unfortunately, after #17, a representative walked outside and told us that Mr. Daniels had to leave for another scheduled engagement.
At first, I was pretty pissed. Seriously? He couldn't accept just a few more people and get through 100% off ALL of the people standing in line? No, later I thought about it. He had a timebox. He had exactly two one-hour sessions. He was going to get through as many autographs as he could but he still had to leave after one hour, regardless. He agreed to sign a specific amount of autographs and he met that commitment... and he exceeded it.
Have you had that situation happen to you as either a ScrumMaster, Project Manager, or Stakeholder? As a stakeholder you feel ripped off because someone else got something delivered and you didn't. As a ScrumMaster, you have to allow the team to commit to do the work. You can't force work upon them. As a Project Manager, you have to explain to everyone that if you let the time constraint slip, you would be asked to do that every time there was a commitment. You've heard it before. Please, just one more thing. Please, just one more day.
Mr. Daniels, you did the right thing. You kept your commitment. If that gig as protocol droid doesn't work out for you, I'd hire you.
