While there are many books and much research on organizational development, this system view combined with some validated learning over time is a powerful way to look at organizational challenges as a coach/consultant. Let’s take a closer look to define these areas then apply some validated learning from my own experience. Business Outcomes – the outcomes desired from the business strategy selected Org Structure – the structure of power and authority to facilitate decision making Incentive Systems – rewards for individual and group performance Work Systems – how people get work done in the organization Collaboration Systems – systems to overcome…read more
Adopting agile is never about about adopting agile practices. It’s not even about adopting an agile culture. While those things are important, if you don’t achieve better business outcomes, adopting agile is not worth the investment. 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 and guide your transformation to measurably show progress toward your critical business objectives.
Agile tends to focus on adaptability, but predictability is most often cited as the reason for an agile transformation.
As organizations scale, product quality often suffers. Agile focuses on quality from requirements through implementation.
Many organizations struggle with 18 month delivery cycles. Agile helps your team accelerate time to market and revenue.
Cost savings are tough to promise, but agile can help make sure you are only spending money on the features most likely to generate revenue.
As companies grow sometimes they slow down and lose the ability to innovate. Agile can help you get back your competitive edge.
Delivering on time is only important if you are delivering the right product. Agile can help you get the feedback you need.
The LeadingAgile compass helps us visualize what your company values from a planning perspective and compare that against what your customer values from a delivery perspective. Many organizations find themselves oriented in opposition to the needs of their customers, and when they try for greater alignment, they find themselves out of sync with the processes governing fiscal responsibility in their own organization. Getting your company and your customers in alignment is a process that can be planned and executed in a measurable and controllable way.
the road map
We don’t start with culture and we don’t leave it up to you to figure out everything by yourself. We help you develop an organizational structure, a governance model, and a metrics strategy designed to guide all your transformation activities. We help you craft a pilot approach to exercise the strategy, validate the framework, and challenge any early assumptions. Metrics guide and inform the outcomes and we prepare your team to sustain the new organization after the coaches are gone.
LeadingAgile offers training, but we are not a training company. Engagements are always a mix of consulting, classroom training, hands-on coaching, and sometimes even staff augmentation delivered exclusively in the context of our cutting edge framework for leading large-scale enterprise agile transformations. Our Compass and Our Roadmap make all the difference in how our services are brought to bear within your organization. Our team is consistently focused on business outcomes and can tie every day-to-day activity to specific business goals we are helping you achieve. Learn More
let your journey begin...
If you’re ready to get started, or even if you’d just like more information, the first step is to reach out and let us know you’d like to talk. Our team will setup a quick call to learn more about your organization, what you’d like to accomplish, as well as your budget and how soon you’d like to get started. Next we’ll put you on the phone with Mike, Dennis, or Jim to dive a little deeper into your goals and current challenges. If we both think there is an opportunity to help, next step is to get in a room and talk. We'll fly almost anywhere for a face-to-face meeting to begin building our relationship with your team.
latest field notes
The LeadingAgile Blog
Risk is a big topic, but generally for beginning agile teams (or any team) it can be calculated in a minimalist way as dependencies. To me, dependencies represent a binary probability. Either they are resolved or not. When paired with value, risk becomes super important to look at because it can tell you how much of that value is in danger. Specifically, we can use it to make informed decisions about investment. Regarding value For now, I will take a look at value through the lens of Net Present Value (NPV) because the program I am currently coaching is already…read more
I think I’ve found myself (somewhat accidentally) at the beginning of a series of posts called ‘debates I find useless… let’s move on’. The latest round of discussion that seems to have spiked (at least for me) this week is the whole ‘to estimate or not to estimate’ conversation. The answer to this question clearly falls into the ‘it depends’ category, so if we are having an argument that involves any kind of absolute, we are probably wasting our time. Even in a domain like commercial, non-governmental, software product development… the one LeadingAgile plays in most of the time… there is…read more
It seems this week more SAFe related stuff than usual made it across my desk… some positive, some negative… some old, some new… but all asking the same fundamental questions. Is SAFe the savior of all things software development? Is SAFe really agile or merely the second coming of RUP? Will SAFe survive or be relegated to the ever growing list of failed approaches that have come and gone over the past 30 years. Here is my take… it doesn’t matter. Agile as it was defined 14 years ago is basically a lightweight framework for building software. Agile is predicated…read more
Why on earth do I need to spend so much of my time in a meeting? This is an absolutely sane question that most of the team members wind up asking at some point in time while I am coaching an organization towards more adaptive management techniques. Regardless of the role, there are other things beyond meetings that we have traditionally declared to be a productive use of time. If you are a developer, then we declare productivity to be associated with time spent writing software. If you are a product manager, then we declare productivity to be associated with time…read more