I’ve had this ongoing discussion with a few of my colleagues who say that the term “Agile leader” is an oxymoron — that the ideal organization is a bunch of Scrum Teams and not much else. Even in an ideal world, I disagree, and here’s why in a nutshell: I’ve never seen, and have not even heard of, an organization that was successful in their pursuit of agility who did not have a strong leader guiding the vision for what the organization can become, motivating people to achieve that vision, nurturing the pursuit of that vision, and protecting, when necessary, the people who want that vision from the people who don’t.
The reason for this is simple and is as old as civilization. As Nicolo Machiavelli observed,
Initially posited by author and businessman Peter Drucker in his book, The Practice of Management in 1954, OKRs find their roots in Drucker’s concept of the MBO, or Management By Objectives. MBOs are an individual-based goal-setting technique based on an annual calendar that required full completion and on which hinged an employee’s salary, or even their employment.
By 1968, MBOs were becoming outdated as attention turned to cost reduction in production, and the term and modern concept of OKRs was introduced by Intel co-founder and then-CEO Andy Grove in his book High Output Management. Applying the process of production to MBOs and advocating measurable, short-term outcomes, his idea became an inspiration to industry professions. This included venture capitalist John Doerr, who, after joining Google in 1999, brought the idea to the fledgling search engine company and popularized the idea throughout the company, as well as others he later invested in.
Project management is a comprehensive and complex field of work that requires extensive practice, skills, knowledge, and expertise. Despite the plethora of resources, certifications and expert advice available today, project management continues to hold its place as one of the most challenging professions.
A study by Gallup shows a staggering fact that only 2.5% of companies successfully complete 100% of their projects. The reasons behind this phenomenon can be many and although frameworks such as agile project management have streamlined this field to a huge extent, project managers continue facing issues and roadblocks on a daily basis.
Setting up a goal is the first step towards implementing an idea; whether it is related to personal ambitions or professional projects. It is important to be able to set goals that are not only easily met but also bear optimum and lasting results.
Project management is all about setting goals and completing the set milestones on a given timeline. When goals are set efficiently, it optimizes each stage, whether it is project planning, tracking, and monitoring, implementation or testing.
I have personal and professional goals. Sometimes, I state them as objectives: complete this book, learn that thing. Those are personal objectives. My personal objectives look like MBOs, Management By Objectives. These personal objectives contribute to my company, but they are not a corporate objective.
Some of my goals are corporate objectives: release that book, build that workshop in service of a greater goal. Those goals look like OKRs, Objectives and Key Results. I can measure my progress towards those goals on a regular basis, and see my results as I accomplish them.
MBOs (Management by Objective) don’t have to be personal. MBOs should arise from corporate objectives. Too often, MBOs are personal — they don’t correlate with a corporate objective. Many people have yearly MBOs that look something like this:
That’s fine if the corporate objectives don’t change throughout the year. And, it’s fine if you don’t need everyone pulling in the same direction.
When I created MBOs with my manager, my projects changed. Sometimes, all the projects changed within a week of my goal-setting. I had other goals for the rest of the year. At the end of the year, when we reviewed my MBOs, we often shook our heads — our corporate objectives had changed, even though my MBOs hadn’t.
Notice how my MBOs optimized for my deliverables, a form of resource efficiency. When Drucker developed Management By Objectives, the idea was to flow the objective down to each person and gauge their results against that corporate objective.
That’s not what happened. We had personal objectives, which might or might not have been congruent with the corporate objective.
Enter OKRs, Objectives and Key Results. Instead of yearly objectives, the people in the organization collaborate to create quarterly Objectives and Key Results the organization wanted.
Objectives have measures: a specific increase in customer retention, increase in customer acquisition, increase in revenue, etc. The objectives are supposed to be SMART goals (Specific, Measurable, Attainable, Relevant, Time-Bound). Then, the Key Results can also be measurable.
OKRs are supposed to encourage flow efficiency, so everyone works to the same objective. If the objective is sufficiently audacious, people will not achieve well-defined OKRs a significant portion of the time.
OKRs provide us a way to create feedback loops on corporate objectives and how well we meet those objectives. If we don’t meet our OKRs, we learn from these feedback loops. We can decide what to do the next time.
In MBOs, each person was accountable for their own work. Too often, failure was not an option. Fail enough and even if you learned, you got fired. You’re supposed to hit the target on every MBO.
With OKRs, each team is accountable for their work, first to tie the key results to the objective. Second, to deliver something and learn. You don’t have to hit the objective target, as long as you can show progress and learn.
So, can you ever have an objective be “release this product”? You can, for an MBO.
For OKRs, think a level higher: what is the value of releasing this product? That’s the objective. What is the corporate objective you realize by releasing the product?
If you have a small organization, you might have several OKRs for the entire organization. If you have a large organization, consider product-line OKRs. When in doubt, optimize up.
When we collaborate on the OKRs, we can make organization-wide goals. That helps with flow efficiency. We can all work to achieve a result greater than what we can do alone.
The organization becomes accountable, not the person.
One organization thinks they have OKRs. Each team has an objective to release their own products. Except, each product is part of a program. Releasing the products on their own does not provide as much value as releasing the entire program. They are using the term of OKR, but they’re treating it as an MBO. They optimize for each team, not the program.
Worse, another organization thinks an objective is to increase a team’s velocity. That notion misunderstands velocity, ignores flow efficiency, and is not an organization-wide objective. This is the worst kind of MBO: a way to punish people if they aren’t “accountable” for a surrogate goal.
Here’s a check on your OKRs, to see if they really are OKRs:
If you can answer yes to these questions, you probably have OKRs. If not, you probably have MBOs.
In part 2, I’ll discuss accountability and what that might mean in an Agile environment.
I often find most organizations think the more metrics they have, the better off they are. Sound familiar? To the contrary, collecting metrics data takes time. If the metrics being reported on are not really valuable, then that time spent collecting data is all wasted time. So, the following is not intended to be an exhaustible list of indicators or instructions. Rather, the intent is to provide context on how anyone can glean information from metrics to demonstrate results toward better business outcomes.
This post focuses on an organization’s desired to have its Scrum Delivery Team predictably meeting its release or milestone commitments.
I will lay out the process in 5 steps.
A journal article from 2016 supports the suggestion that monitoring goal progress is a crucial process for setting and attaining the goal. Additionally, the article states that progress monitoring had a larger effect on goal attainment when the outcomes were reported or made publicly available, and when the information was physically recorded.
I believe leading indicators are the mechanism by which we monitor goal progress and reviewing that progress frequently by way of dashboards provides the larger effects of goal attainment.
I will assume you are already familiar with LeadingAgile’s Compass. Comparing the planning characteristics of a company with the planning expectations and needs of a client allows us to put your company, or your division, or even just your product area into one of four quadrants. The quadrants help us understand more clearly some of the challenges you might experience meeting customer expectations, why you are struggling or might struggle to adopt agile, and how to talk about the steps necessary to safely and pragmatically move your organization forward.
I am going to focus on organizations that are actually in alignment with their customers’ expectations, but may struggle making and meeting commitments due to lack of clarity around the requirements, poor estimation, and extreme variability in the rate in which individuals can actually complete work against the estimates. Again, sound familiar? These organizations often have highly structured PMO organizations, very disciplined governance, long-term planning and tracking processes, but still struggle to make and meet commitments on a regular basis.
Your journey toward greater business Agility starts by identifying what outcomes are most important to your company’s success. This knowledge helps you lay a foundation for making decisions about how to tailor your approach to measurably show progress toward your critical business objectives. For this blog post, our goal is Greater Predictability.
In our example, our desired outcome is to have teams plan, coordinate, and deliver predictably enough to meet a release level commitment.
That’s not too much to ask, right? But what do we need for this outcome?
Backlog items need to be appropriately sized. They need to be ordered and prioritized to capture work needed to develop product or deliverables.
A stable team has everyone and everything (skill sets, tools, etc.) needed to deliver working, tested, documented, deployable product.
This means deliverables meet defined acceptance criteria, have been reviewed and approved by product owner/ stakeholders, have been tested, and are shippable.
For our example, here are two key results:
The key results are also known as lagging indicators. The metrics to measure them are known as leading indicators. You can read more about leading and lagging indicators here. The important distinction is that a lagging indicator is one that usually follows an event. You can use the leading indicators to make changes to your behavior or environment, resulting in more positive key results and better outcomes.
Any of the major Agile ALM tools will provide leading indicators, given you configured the tool correctly and you are consistent on how you (correctly) use it. You just need to know what a meaningful indicator is. Atlassian Jira, CA Agile Central, VersionOne. They all work. Given these, I don’t discount the value of physical boards and spreadsheets. But since most of our customers are struggling with having many teams working in parallel, an ALM tool can pay for itself through less duplication of effort and higher quality of data.
Let’s use Story Point Completion Percentage as an example leading indicator. Capture key information about the metric, to ensure there is a shared understanding. Metric description, how its calculated, when to measure, acceptable thresholds, and the source location are all critical for us to have a share understanding.
An example would looks like this:
Story Point Completion Percentage measures Delivery Team predictability. It is strongly correlated to the team’s stability and governance ability to manage dependencies. It is paired with the User Story Completion Percentage.
Total Story Points (Accepted) / Total Story Points (Committed)
Committed Story points are calculated at Sprint Planning; Accepted at Sprint end.
≥90% (Green) | 80-89% (Yellow) | < 80% (Red)
Within an active project, navigate to the Iteration Status page. One of the helpful elements of this page is the ability to see if the team has committed to an appropriate level at Sprint Planning ( Planned Velocity graph) and how they are progressing toward the end of their Sprint ( Accepted Velocity graph). Point Completion Ratio is calculated by using the Accepted Velocity graph. (N of N points)
That’s it! Start with the outcome first and you lower the chances you’re going to be wasting your time with meaningless metrics. As I noted early, leading indicators are the mechanism by which we monitor goal progress and by reviewing that progress frequently via dashboards, we increase the odds of reaching the goal or outcome. Use the dashboards provided in your ALM tool or build your own.
The moment I heard it, my acronym allergy kicked in: OKRs. I’d done S.M.A.R.T. goals at another company, and they kind of sucked. Ditto for quarterly As & Os (accomplishments and objectives). Obviously, this OKRs thing was going to be more of the same.
And they did indeed kind of suck. We’d start working out OKRs for the next quarter with a full month left in the current quarter, so it felt like we were always in planning mode. Then all quarter long, I’d go down my checklist of KRs doing the same things I’d probably be doing anyway, wondering how that month of formalizing them wasn’t pointless overhead.
OKRs (“objectives and key results”) n. — Yet another corporate goal-setting framework.
The one thing OKRs had going for them was that people up the chain were setting high-level objectives, then leaving it to the people closest to the actual work (i.e., people like me) to decide exactly how we were going to contribute. That part totally makes sense, and I appreciate that level of autonomy.
Still, OKRs felt like a confusing and unnecessarily process-heavy way of shooting for the stars.
Then I realized I’d been doing them wrong in a bunch of ways. In fact, most of us were getting something about OKRs wrong. No wonder it was confusing. Long story short, we straightened ourselves out and now OKRs are actually fruitful — I’ll show you some real-life examples below.
If you hate OKRs, you owe it to yourself to at least make sure you’re doing them right (seeing as you probably have to do them anyway, rage notwithstanding). Below is a list of mistakes that were running rampant around, plus a couple bonus anti-patterns you should be aware of.
Full disclosure: we haven’t eliminated all of them. Yet.
If you’re already familiar with the basics, skip to the mistakes below. But for the uninitiated… Objectives and key results (OKRs) is a framework for setting goals, typically on a quarterly basis. Your team sets 3–5 high-level goals (objectives) to pursue, along with 2–3 success measures you’ll use to determine whether you’ve reached it (key results).
At the end of the quarter, you score each KR on a sliding scale from 0 to 1 (0 = no progress at all; 1 = you hit or exceeded your target; .1-.9 = somewhere in between). During the quarter, you check in and predict what the final score will likely be, based on how you’re tracking so far. This keeps OKRs fresh in your mind and serves as an early detection system for OKRs that might need some extra attention.
“Ecosystem” isn’t a helpful objective. Neither is “customer experience.” They don’t say much about what you’re trying to achieve or where you want to go. They’re nice themes, sure. But they’re not really goals.
Instead, write your objectives such that you can look back later and see clearly whether you met it or not.
One of our design team’s objectives is, “Improve our craft, velocity, and quality of design decisions.” They paired it with KRs like “50% of product releases have a passing UX scorecard” (I don’t know what a UX scorecard is, but I trust our design team does).
Your KRs shouldn’t be an exhaustive list of every single thing you and your team are doing. Stuff that falls into the “business as usual” category like fixing bugs or closing out the quarterly books doesn’t need to be there.
If your objective is to change the way in which you go about business as usual, that might be worth including — “Improve turnaround time on customer-reported bugs” or “Reduce late expense report submissions by 20%.”
OKRs are your highest priority items, and “just enough” is enough. FWIW, I’m a senior-level individual contributor and I typically own 1–3 KRs each quarter.
For a long time, I wrote my KRs as nothing more than a to-do list. Check ’em off when they’re done, score ’em all a 1 (more on that in a moment), and call it a day. Satisfying, sure…but again: formalizing my tasks as KRs just felt like busy work. Plus, there were times when, halfway through the quarter, I realized the task wouldn’t get me closer to the objective. “But it’s a KR! I’m honor-bound to follow through on it!” Ugh.
My lightbulb moment was when I got hip to the fact that the “R” stands for “result.” (Duhhh.)
So instead of saying “Publish 3 blog posts related to the Team Playbook,” I started saying “Increase traffic to Playbook-related posts by 15%.” How I get that 15% increase is flexible. I could promote old posts, optimize them for search, publish new stuff, or some combination thereof. Also, getting to a 15% increase feels like a juicy challenge. (‘Cuz honestly, I could churn out 3 posts in my sleep. They’d get crap results, but I could do it.)
Think outcomes — not output.
You may have seen KRs like, “Better customer engagement.” How could you even score that?? It’s super subjective, and therefore meaningless in the context of goal-setting.
When you phrase KRs as a measurable result, however, they’re easy to score. Just do the math. Going back to my, “Increase traffic to Playbook-related posts by 15%” KR above, let’s say I manage to increase traffic to my blog posts by only 5%. I divide 5 by 15 and boom: my score for that KR is .3 (roughly).
Objectives, on the other hand, are often articulated such that you can’t score them objectively. But that’s actually ok. Take the average of all the KR scores rolling up into it, and you’ve got your O score.
There’s this famous preso from Google about OKRs that talks about how a score of .7 is considered good. That led to some confusion on our team as to whether you score your KR a .7 vs a 1 if you hit your stated target. (The argument being that scoring it a .7 leaves room for you to exceed it and “get credit” for over-achieving.)
Here’s the deal. If you hit your KR’s target, you score it a 1. At least, that’s how Google does it. If you exceed your target, you still score it a 1 — and think about setting a more ambitious target next time. Which leads me to…
The reason a .7 is considered good is that your stated targets are supposed to be really frikking hard to hit. If you’re nailing them most of the time, you’re not stretching yourself. Or, your KRs are actually just tasks (see above) that get a binary 0 or 1 score. Maybe it’s both.
My team once set a KR of doubling SEO-based traffic to one of our microsites, which, honestly, felt like a pipe-dream. But lo n’ behold, we did it! And we learned a ton along the way, which wouldn’t have happened if we’d set a target we could’ve sleepwalked to. This was my other lightbulb moment.
Don’t keep chipping away at a rock if it’s the wrong rock. Things change, new information comes to light, etc. It’s ok to remove or abandon an OKR if you no longer believe it’s the right thing to do. Score it a 0, and replace it with one that is right.
An important aspect of OKRs is that zeros are not punishable. (If they are, then you’re really doing it wrong.) Instead, zeros should prompt questions. Why did we miss so badly? Why was this the wrong goal? How can we set a better goal next quarter? If you learn something from your zero, you haven’t wasted your time.
After a few quarters of doing OKRs the way they’re supposed to be done (or close to it), I generally feel more focused. It’s easy to figure out what I should be working on at any given point in the quarter. And if someone requests additional work from me, I can weigh it against OKR-related work and give them a yes/no answer quickly.
I also feel more connected to the work people around me are doing (and being a remote employee, that’s doubly important). My teammates and I often own individual KRs that feed into a common objective, which gets us sharing info and ideas more than we used to.
As a bonus, getting comfortable with setting stretch goals keeps me from wallowing in mediocrity. Complacency is a career-killer, and I’ve got too many years before retiring to rest on my laurels just yet.
So yeah: I’ve gone from OKR hater to born-again OKRs booster. Which makes me wonder what else in my life seems kinda sucky…but only because I’m doing it wrong.
We are going to start a new year in a coming week and each of us is thinking about a better job or position or even improving current job in a company. From my experience as a developer, holidays are a good time to take a look at what you have done in the current year and what are your interests for the future. Here there are some steps you can take to start your new year very strong.
First of all, you need to take a look at what you have done in the current year. We usually review our work in different steps but in this time of the year, it is good to look at it from different perspectives. One way is to make a list of all of the projects and tasks you have done, while also considering the tasks you have not done. Then try to score them based on the importance of tasks from the company perspective or technical perspective. At the end, you can sort the list based on your scores and it gives you a better view of your progress.
In the previous step, you made a list which has been sorted based on scores. Now, you can separate your achievements into one list and in another list, you can write your failures. What failures means here is a task which has not been done in time or even has not started yet because of lack of time or skill. So, it doesn’t mean a real failure but it means the plan in which that task was supposed to be done has failed.
As a technical person, it is essential to follow technical news, looking at trends and considering the new tools and latest updates for tools or programming languages you use. These days, we are spending a lot of time on social networks. On the train, bus, or even in the breaks at work, people are busy checking emails, Facebook, Instagram, WhatsApp, and Snapchat. If this is one of your habits, I suggest changing your habit for a short time and try to spend that time on reading an article or looking at the new updates of a tool or language you are using.
After following trends and studying new articles you may come up with some ideas about areas you want to improve or skills you want to gain. To achieve any of these, you need to increase your knowledge and practice. So, it is obvious this process takes time, from days to months, but in this step just make a list of topics which you are interested in and then try to score topics based on the importance of each to your current job or maybe a next job. The importance here means how much that skill or technic is needed or necessary to know, so one subject can be the first item for someone and be at the end of the list for somebody else.
Now, it is the time to choose one of your topics which you like to do first. Of course, there can be a lot of things you want to know or learn but the aim of these steps is to help you to get one learning subject done, so focus on an area or subject which can fit your current situation and the time you have in your holiday. For instance, if you want to become a project manager then it is not possible to do it in one day or a week, but if you like to learn about one tool or start a foundation course about a programming language, you can probably do it in your holiday. If it makes you confident enough, start using it and continue it after the holiday.
Today, there are a lot of sources for online courses. You can find a lot of useful course from Lynda, Udemy, LinkedIn, and many other websites. The duration of the courses usually is less than 2 hours so it is possible to finish the course in less than two days. As I mentioned before, it is really important to focus on one subject in order to make it happen at the end.
Nothing better than new skills and ideas to provide motivation to return to your job after the holidays. I think it is possible to make use of part of your holidays to have a better understanding of your strengths and weaknesses and make a plan to improve your career.