OKRs and KPIs

Objectives and Key Results (OKRs) and Key Performance Indicators (KPIs) are critical to the success of a product focused organization. It is by these means that we measure success and know whether or not we are doing the right things.

 OKRs align teams with the larger corporate strategy, they should give the teams autonomy in execution because they are only specifying where to go and how to measure whether or not we get there, not how we get there. That should be left to the team keep them aligned but free to innovate and execute to the best of their ability.

 Objectives are big and bold and inspiring, key results (often KPIs) are the details of how well we are implementing those objectives. They should be specific and truly measurable. They should be short term measurements to allow for course correction. They should be created by the teams in conjunction with leadership and the team should be truly able to own those metrics because they do not need to rely on anyone else to affect them for good or ill.

 Creating good or great OKRs and KPIs is hard work but worth the effort. They are simple in concept and difficult in execution. There is an art and a science to them which is well worth researching, perhaps I will blog about this in the future.

 I do not know of a better way to measure the success of a product organization. I believe that OKRs and KPIs will become the industry standard over time. Start learning about them and using them now and you will see the benefits for yourself.

The Courage to Transform

In order to successfully transform an organization I believe it takes leaders that set a vision, set an example and follow through on their promises. Leaders who are brave, willing to fail and who serve the people that they lead.

 Successfully transforming also takes employees who are willing to trust in their leaders, who are willing to change the way they are used to doing things, learn new skills, (often the soft-skills count the most) and take risks.

 Successfully transforming an organization takes a willingness to weed out the people who do not share in your vision, who cannot adapt to a new way of working, leading and being. There will always be those who fight for the status quo, either openly or subconsciously, suppressing any change with all their might.

 Successfully transforming takes great courage and brings real pain in changing, change is hard and it always hurts something (most often our egos).

 Transformation is creative destruction, it is catastrophic by the definition: "involving a sudden and large-scale alteration in state." There is no change without effort, without upset, without consequence. Be brave, it is worth the journey.

Failure and Success

In order to succeed you have to fail… a lot. This means you have to experiment and measure and evaluate and iterate on what you are doing. This means you will get better and better as you learn more and more what not to do, in order to learn what to do. It also means you need good leadership.

 It is surprising how many large companies do not have the stomach for this. They have the money to spend, they can absorb the risk, they can afford to fail yet they refuse to experiment, they squash innovation.

 I have seen things like contests/code-a-thons to come up with new ideas, with the selected winner chosen to try out but never tried out. I have seen innovative business/product ideas killed because “it just doesn’t fit with our model’.

 There is nothing more disheartening than having your ideas crushed beneath the heels of “that is not the way we do things around here” for no good reason, for fear of failure. There is nothing more heartening and supportive of innovation than saying “try it, measure it and we will see how it works out.”.

 I personally have put my job at risk to protect teams that were innovating, experimenting and trying to forward the corporate strategy and success and have even lost a job doing so. If your company is not innovating then you have the wrong people in charge of it, it is leadership and management that creates the environment for innovation, they are the sunlight, or they are the darkness and nothing much grows in darkness.

Product Organizations

I have seen too many product organizations where the Product Owners are not empowered to actually own their products. Too often it is someone “above” them dictating or managing what they are doing, when what should be happening is servant leadership supporting the Product Owner.

 Product Organizations need to be collapsed so that only the essential people are involved, no question there is a need for sales and marketing professionals and many supporting players but it is in the executive and leadership realm that middle management needs to be removed and true servant leadership needs to be established. The leader of the product organization should have Product Owners reporting directly to them and they should not be telling POs what to do but only “where to go” to fulfill the strategic goals of the company, then standing back and letting them go there by any means they deem productive.

 Product leaders need to support their POs, coach them, mentor them, empower them and stay out of their backlogs, stay away from suggesting features or being involved in design. They should help create the OKRs and KPIs used to measure the success of the products, they should run interference and provide air cover for experimentation and failure.

 Product organizations need middle management like a fish needs a bicycle. Let’s collapse the organization down to its essentials and truly lead them into successful delivery of business value.

Project to Product

There is a lot of talk these days about project to product organizations. I would argue this goes hand in hand with an Agile transformation. You cannot effectively have one without the other. A few of the reasons why follow.

 No one “owns” the application in a project organization, a project team is formed, and dissolves based on delivery of the project. With a product team you have a team that owns the product long term, it is then that you get the benefits of ownership (deeper business knowledge, greater skillsets, higher quality, faster delivery).

 It is the difference between the short-term ownership of the project to the long-term ownership of the product. You don’t lose time forming project teams, the team is already formed and normed (with no J-curve) and ready to go. The product team has deeper engagement, morale and more innovation because they are not treated as resources to be shuffled based on the next project.

 Funding is simple and a fixed cost, the cost of the teams combined salary, you can count on this vs. trying to fund a project upfront based on guesswork and then dealing with the overruns which require negotiation and disappoint expectations or underruns which encourage gold-plating the application with unnecessary features. Funding teams is simple, even in the world of CAPEX/OPEX, you simply apply your capital/cost to the product based on the team’s presence, working on the application.

 You are able to measure the value you are delivering to your customers based on OKRs and KPIs vs. measuring success based on delivery on-time and on-budget, on-scope which just tells you how well you did with your project not how well your product is doing on delivering against the corporate strategy.

 These are only some of the benefits and methods, there are many more. The product model of organizing is here to stay, it beats out the project model every time in today’s complex and shifting digital environment.

Customer Interaction First and Foremost

If you are in sales and are not selling something that your customers want and need, you will not do very well in sales.

If you are developing software and are not building something customers want and need, you will not do very well in product development.

It is amazing and sad to me every time I see a team disconnected from their customers, (whether internal or external to the business) when it is such an easy and powerful thing to do.

Guessing what your customers need and want is not good to count on unless you are well used to running experiments and that is the only real option available to you because you are being so incredibly innovative that there is a need for strategic secrecy.

Much more often what happens in my experience is that someone talks to the customer once, upfront before development and then delivers it (often without feedback) when it is fully cooked. This is Waterfall behavior and a major reason for failure (you can do everything else right but do this and it won’t matter) because you are still flying blind and do not know if you are doing the right thing until end when it is too late to change it.

What should happen is that you talk to the customer upfront even when you are designing your solution/product and then engage them throughout development by letting them see early features and functionality and kick the tires and try it out as you go along, ensuring that you are building something that the customer needs and wants to the greatest degree possible.

Even more so, you should allow the customer to interact directly with the development team (in Scrum) and not just the Product Owner or a Business Analyst. Doing this eliminates the game of telephone where you are passing on second-hand information and thereby changing the message (unavoidable) by passing it from person to person before it gets to the developer actually building what is being requested.

Bring your customers into the fold and you will not regret it, just be careful of one thing which is the “Homer builds a car” syndrome (see the Simpsons episode, it should be required viewing for every team) which results in building the 80% of features the user will not use instead of the critical 20% they will.

Bring the customer in, it is where they deserve to be and where your most successful product development will reliably happen.

Scaling Scrum

Far too often I have seen scaling Scrum become an overly complex endeavor which actually does two things, either it crushes the empowerment of the Product Owners and the innovations of the development team or it adds needless time and dependencies across teams delaying the delivery of value to the customer, or both.

 Scaling Scrum is really quite simple in my view but, there is a necessary pre-conditions which are critical to have in place first. Before I get to that how do I recommend scaling? Simple, SoS (Scrum of Scrums), the least defined, most open to interpretation version of scaling that I know of. Because it is so simple it lends itself to modification depending on circumstances which allows it to be ultimately adaptable, if somewhat informal. If something more formal is required for any reason I would recommend Nexus because it is the closest to SoS in nature and therefor performance.

 These methods of scaling would fit all situations I have ever seen in my career (which is a lot of them) if again the necessary pre-conditions are met. This includes every SAFe implementation which companies have struggled with.

 The necessary pre-conditions are, one, that you truly have cross-functional teams and are not deploying siloed teams (one team doing data, one team doing architecture, one team doing anything but full-stack feature development). Siloed teams are the bane of scaling, they build in complexity, time and dependencies which are a nightmare to manage and why something like SAFe even exists.

 The second pre-condition is determining that you even have to scale in the first place. Too often I have seen major programs with many teams trying to scale something that could have been solved with one or two truly cross-functional teams in less than half the time and one tenth of the cost of the scaling solution in terms of human hours on the project.

 The third pre-condition is that you stay out of the way of teams and empower the Product Owners to say yes and more importantly no to features and you allow the development teams to innovate on how they deliver the requested features.

 If you can do these three things you will rarely and barely have to scale with Scrum. I have seen this proved to me time and again and would highly recommend you actually try it.

QA in Scrum

I do not believe in QA as a separate discipline (and a separate person) on a Scrum team. I know this is unpopular, or at least it has been at some of my larger clients, companies I have worked for. It definitely does not make me popular with QA professionals.

 I believe that separating the discipline of QA from development is an artifact of Waterfall thinking and acting. It has no place in Scrum because it sets up a mini-waterfall effect on a Scrum team which is hard to manage and defeats the purpose of Scrum at its best.

 What I believe QA should be is built in from the beginning, with TDD and unit tests, with automated testing (integration, browser compatibility, security, performance, monitoring etc.) and that this should be done by the developers doing the work so that they get direct feedback on their work from themselves and each other. They are the ones that should have a vested interest in whether they are going to be woken in the middle of the night with a production support issue. They are the ones who can most effectively blend the act of coding with the act of testing.

 This doesn’t mean we get rid of QA professionals but what it does mean is that their focus changes towards automation so that they can run alongside other developers as they work without the Waterfall effect, and that they also build up their coding/DevOps skillset so they can be more valuable to the cross-functional team then just writing and running test scripts.

Quality needs to be built in from the beginning, not thrown over the wall to someone else. It is a value that needs to be instilled in the product, not added after the fact. Do this right and your quality will go through the roof. It will never be perfect but will be as perfect as can be achieved.

Working Remotely in this Time of Covid

If you have never seen a high performance fully co-located Scrum team working together in a shared space (with places to isolate as needed), with sticky notes on a whiteboard to track and manage the work, then you have not lived. Truly amazing things are possible in this kind of situation. People perform at the top of their skillset and with great integrity and humility. People communicate better than any other scenario. Progress is transparent, quality is job one and the customer is the focus of the product. Of course, this does not describe every co-located team, it is entirely possible to have a poorly performing team as well. For the sake of the point I am going to make let’s assume that all things being equal the team is awesome.

That same awesome team can adapt to working remotely, indeed they may work remotely already for part of the time to avoid interruption of their flow or because one or more team members cannot be there in person for a short or longer period of time. So, they may already have team conventions in place to ensure that they can still work together effectively as a team. Regardless, fully remote working over a long period of time can work and does work if you have a great team, however it never works as well as a fully co-located team and that fact I do not think will ever change. If you have a poor performing team, remote working just exacerbates their issues and can seriously degrade their already poor or mediocre performance. This is never recommended if it can be avoided.

In this time of Covid though, working remotely is the only sane and safe thing to do for your workers, so how do you make the most of it? How do you get the best performance out of your teams in this stressful situation? First and foremost, you create high performance teams, you instill the Agile values and principles, the Scrum values, Lean values and you make them real through practice and support of them. You then focus on your Agile practices and hone them over time. You do everything you can to replicate in person environments through video conferencing (with the cameras on!), good collaboration tools and an ethic of direct communication with each other (no email! Limited chat!) rather than some overblown process or tools requirement to simply talk to each other.

You can do it, you can create high performance teams in a remote working scenario, it just takes serious dedication and an ongoing, uncompromising effort to continually improve. There is no downside to this endeavor, you can only get better.

Agile Release Management

Release management should be simple when you are working in an Agile way.

You establish the MVP for the release and ensure that you can achieve MVP with the release by only committing to what can easily be achieved in the given release window, based on measuring velocity, good sizing of the work and you leave room for nice to have features which may or may not be a part of the release depending on how the MVP goes.

You make sure that you have the skills and people on the team who can ensure that the release is documented, with training/help material available for the users, even if they are only on the team for the time needed to do this, they should be embedded.

 You should be able to rely on tools to show scope, track velocity and project when a release is going to be finished. You use automated testing to ensure quality, (integration, performance, security etc.).

You let the team (usually the Product Owner with input from the development team) decide when to launch the release. They are the ones who know when it is ready to go and will not be a support nightmare due to lack of quality or completeness.

You use IaaS or at least the right tools to ensure an automated launch, ticking all the boxes that need to be done to ensure a successful and stress-free release.

Boom! It should be simple, if you are working in an Agile way (which is the challenging part to achieve). If not, you will disappoint expectations for the release in terms of scope and schedule, fire-drill over every release step, waste time, energy and customer satisfaction with extensive production support after the release.

Measuring Performance

When measuring performance in an Agile environment, there is one typical problem I see over and over again, personal performance measurement takes the front seat and most everything else is not truly measured or even defined for measurement. This is “bass ackwards”.

Individual performance management should be handled by the team, they self-select out poor performers because they intimately know who is pulling their weight on the team and who is not. They know who is good at their job and who is not competent to the degree needed and wanted. They (the team) should escalate such issues to management for resolution but annual performance evaluations for individuals should go out the window.

Performance in an Agile company should be measured in two ways, the first is team performance in delivery of value and secondly OKRs and KPIs. There are two reasons for this, the first is that team performance is what matters, not the isolated contribution of each individual. On a truly cross-functional team this is nearly impossible to do and of no real value. You cannot measure anything but the sum of a teams parts, nor should you because that is not what matters, what matters is are they delivering value to the customer or not? How do you measure this value delivery? By OKRs and KPIs. By aligning the teams activities to corporate goals and strategy and then measuring performance against those through specific and measurable metrics and you leave the team alone in how they meet their performance goals.

You leave the “how” up to the team and focus in OKRs and KPIs on the “what”. This is how you measure performance. This is how you know if you are on the right track and how well you are doing (as a team).

Measuring Agile Maturity

Most Agile maturity models focus on the Scrum team itself and the immediate organization around them such as DevOps (which should be part of a Scrum team anyway see my previous post). There is a fundamental problem with a model like this (which most everyone uses including surveys of the state of Agility such as the State of Agile Report) is that it focuses on the practices of the team and not the culture of the organization.

Culture is the most important aspect of Agile, what kind of culture the company has is the most reliable indicator of whether or not they are Agile (i.e. practicing the Agile principles and values described in the Agile Manifesto and the Scrum/Kanban values and lean principles). You have to ask questions like:

·      Is there a culture of trust or fear?

·      Is there a culture of continuous improvement?

·      Is there a ridged hierarchy and silos or a network of truly cross-functional teams?

·      Are Product Owners truly empowered to own their products?

·      Is there a culture of transparency?

·      Are products fully aligned with a declared corporate vision and strategy?

·      Does the culture value experimentation?

·      Does the culture value truth and integrity?

·      Does the culture value servant leadership?

 These are the kind of questions a company should be asking itself if it truly wants to be Agile. Team practices flow from corporate values not the other way around. A team can implement practices all day long but if the culture does not support them, they will be crushed, sooner or later.

When I evaluate Agile maturity, these are the first questions I ask (among others) and I get to the team practices last because they are the least important in the big picture.

DevOps and Scrum

I do not often see DevOps being well practiced with Scrum. To me, DevOps means doing all the infrastructure, monitoring, performance testing and releasing (etc.) from within the Scrum team itself. This means you need the skills on the team whether they are developers themselves (which typically for me has worked very, very well) or at the least having someone(s) devoted to DevOps on the team as a regular working member, not off in some operations group hidden behind a service request system.

In large organizations this may seem like an impossible challenge to make happen. I do not see it this way, they only thing in the way is politics and that is solvable. A great many teams suffer because they do not have DevOps skills on the team, they suffer, and the company suffers because this is not the way to a quality product (with quality built in from the start). This is a way to silo expertise which results in products which have to be fixed after they are created or even after they are deployed.

While we do not live in a perfect world where having DevOps on the Scrum team will solve all problems, it solves so many that it is without question worthwhile to pursue, even in large organizations.

Status Reports are Useless

For the first half of my career to date I worked in Waterfall and so I crafted many status reports. I say crafted because that is what they were, they were not written plainly to objectively tell the truth, they were manipulative, written in order to skew information away from blame with a usually optimistic view of the future based on guesswork. If they were pessimistic about the future, they were either extremely cautious or overzealous in proclaiming a projects failure

I tried to be honest and would often be chastised for it and had my words either changed outright in the status report so as not to alarm stakeholders or more often the people I wrote my status reports for would soften my words in the status reports to their own executive superiors. 

Maybe I have just been unlucky, but I have seen many others go through this same meat-grinder of the truth, which is why I like Scrum so much. 

In Scrum the idea is that you show your work, you show what is working now, you show a working increment of software built with quality in mind. You show your progress in this way, a way that cannot be misconstrued (if you are doing your Sprint Reviews right) by politics or fear. Don’t get me wrong, there are ways to lie in the Sprint Review as well, but it is all too easy to catch those out if you know what to look for. I absolutely see status reports and Scrum like oil and water, they do not mix. The one does not require the other. May status reports go the way of Waterfall and good riddance.

Issue and Risk Logs Are Where Information Goes to Die

I have seen (and written) a lot of risk and issue logs in my day. I have never, and I mean never seen them actually used to any good effect. They get created, they get reviewed for a while and then they die on the vine because they are not valuable in the end. They get ignored by the people that matter most, (who I think assume since things are written down that they are under control) those stakeholders who could actually do something about them. Rarely do I see issues or risks “closed” due to executive or other actions, they just resolve themselves with time or are determined to have never been much of an issue to begin with.

 I have come to view them as a simple CYA (Cover Your Ass) exercise. In my view they are created simply to assure ourselves that we did everything we could to avoid having them affect our work and as an out in case of failure, we can point to them and say, “this is why we failed”.

 What is much more effective in my experience is to actively work issues until they are no longer issues by making it unacceptable to have any outstanding issues for any real length of time, if you cannot resolve an issue quickly then it just becomes a constraint or an impediment to progress, but the point is that it should always be actively worked until it is resolved, period. Make it visible yes but more importantly make it go away. If you cannot do that, then document it as such and move on but don’t review the list of things that went wrong every week. It serves no real purpose and is demoralizing and fear creating at best.

Do We Need Product Owners?

My unofficial mentor Mike Cohn recently asked this question in his newsletter and then answered, “It depends”. I take another view, which is not only do we need Product Owners, we need to stop suppressing them as Product Owners and start putting them in the entrepreneurial role they should have always been playing. Too many organizations see Product Owners as simple order takers, scribes for stakeholders to document the “requirements” they have. This is not the intent of the role at all. The PO role is the person who gets to decide what a product actually is at the end of the day. They are the ones who get to make that determination because they “own” the product!

Too often (most of the time in my experience), the PO feels completely unempowered to make key decisions about the product, usually because they are. They are not trusted to make decisions they are simply relied on to do what the stakeholders tell them to do. Because of this they are not truly accountable to the success or failure of the product, they cannot be because they did not have the power to make choices.

A Scrum team needs an empowered, entrepreneurial PO. One who drives a product forward and makes sure it is what the customer needs and wants and what will deliver value for the business. They need to be “untied” and let loose into the world to succeed or fail as they will.

In Praise Of Command And Control

I initially wanted to title this post ‘Command And Control Is The Primary Impediment’ but found I could not because I felt that would be misleading. Misleading in the sense that I would seem to espouse never using command and control as a method of management, especially in an Agile company on a Scrum team.

On the surface this is actually correct, command and control is the antithesis of what is required for a Scrum team and an Agile organization to survive and thrive. What is absolutely needed is self-organization and self-management in teams and servant leaders as managers and executives. Yet this does not mean that command and control behavior has no place in Agile, no place in Scrum. It does in my view it is just a subservient role.

Command and control is useful when it comes to breaking a deadlock when a team cannot make a decision or between teams differing priorities but most especially when dealing with organizational impediments outside of a team’s control. Sometime command and control is the only way to get something done. Especially when a team is not used to self organization or is flat out refusing to take responsibility for something they should.

In my view the best leaders know when to command and when to be servants to those that they lead. It is not an either or proposition but a ‘both and’ situation.

Craftsmanship At Speed

The Agile Manifesto and Scrum have many things in common and I would like to focus on one of them for a minute, this is the idea of craftsmanship at speed. Craftsmanship is something that has been lost for any organization who does not value competence over cost. It is shortsighted to think that just good enough is good enough for the future, just good enough to get by now will cause nothing but problems in the future, this is disposable code, this is desolate design, this is quantity over quality.

To truly follow the Agile principals and to truly follow Scrum requires a team to reach for excellence in everything they do from design through development and delivery. This enables agility, this ensures the future is not full of bug fixes, this meets or exceeds expectations. If you truly want all the benefits possible you need to enable creativity and you do this by encouraging craftsmanship at every level.

The speed part means delivering early and often, getting feedback and learning from it in iterative and incremental units. Speed cannot sacrifice quality else you will lose whatever you have gained down the line. True speed is only possible with craftsmanship, true speed is sustainable and suitable to the product being crafted and some things should never be rushed to save time now, they should take time now in order to save time later.

Craftsmanship at speed is hard, especially difficult if your organizational culture does not support it. It is truly a revolutionary act in such a situation to insist on it. Once you do Agile is yours.

People Are Not Resources

I have a pet peeve that I am never going to win against yet I do not think I can ever accept the status quo. The peeve is calling people resources. To me a resource is a thing and people are not things they are people. Even the term “Human Resources” bothers me because as I understand it comes in a direct descendence from Frederick Taylor and his thinking about people as essentially cogs in a machine. I do not see people as easily replaceable, each group of people has their synergies and changing even one can change the nature of the whole group.

I often run into the attitude that you can make a team out of any collection of people and while I agree in the most basic sense that you can, if you want the best teams you do have to craft them just as you would a winning sports team. Not all teams may be highly visible or work on the most important projects and may not attract the top talent however, you still should craft your teams, there is an art not just a science to doing it well and of making the most out of what you have available. People are not cogs, they are people and to treat them as anything less than that does a disservice to them and in some sense dehumanizes us all.

Continuous Learning

I have been working with Scrum and Agile for 15 years now and I still learn something new just about every day. Each and every team I work with, every manager, every executive, every organization is different and because of these differences what I thought I knew before often does not apply to the current situation. I learn on the job daily. I learn outside of working by pursuing my ongoing and ever-broadening interests in what I think supports “Agile” in mindset and in practical application. Most recently I am focused on my emotional intelligence skillset and learning to better recognize what people may be feeling and how to interact with them most productively in any emotional state. All of this starts with learning to recognize my own emotional state at any time and to add depth and nuance to describing what I am feeling and why I am feeling it. This may not seem to be related to being an Agile coach but for me it most assuredly is. The better I understand myself, the better I can understand other people, the better I understand other people the better I am able to work with them. All of this is just to say that I am continually learning and I do not believe any good or great coach can ever stop or would ever want to stop learning. There is so much to know and so little time in ones life to learn it that I know I will never be done learning. I hope you will never be done learning either. This simply makes the world a better place for all of us.