How Easily Can We Import a Lean or Agile Framework Into the Organization?

No framework will ever fit a specific organization without some custom tailoring. Organizations are complex systems, with many superficial similarities. However, as experience implementing frameworks shows, there will always be some need to adjust the framework to accommodate the structure, culture, skills, and other important traits of a specific organization. Therefore, leaders and managers need to incorporate these adjustments into their transformation strategy. Continue reading “How Easily Can We Import a Lean or Agile Framework Into the Organization?”

What Organizational Concepts Matter the Most to Agile at Scale

The team is responsible for its process. Teams employ their local knowledge about what is required to do their work, complementing required enterprise standards. The team agrees to use and improve its own processes. Processes exist to serve the people, to help them get their work done. No process is perfect; when problems arise, the team is responsible to stop, change the process, and start again, all without affixing blame to any one person. Continue reading “What Organizational Concepts Matter the Most to Agile at Scale”

What Makes an Organization “Mid-sized” (or Above)?

In teams, peer-to-peer relationship is the glue that coordinates everyone. In larger organizations, peer-to-peer relationship can no longer keep the higher number of people connected well enough to accomplish a shared purpose.

That is when Lean ideas and structures pick up and create… This article discusses differences between team-sized and mid-scale or above, and some factors to consider in determining where an organization fits on this spectrum. Continue reading “What Makes an Organization “Mid-sized” (or Above)?”

How can We Use SAFe® in Smaller Organizations?

SAFe can be applied to smaller scales than those for which it was designed by treating it, not as an “off-the-shelf” approach, but rather as a thinking framework and collection of valuable practices to be mined according to an organization’s situation.

While this is good for the consultants who ride these waves, it doesn’t serve clients well. No “solution” works for every organization or even most of them, because no two organizations are at the same place when they become ready to make significant improvement.

There is undoubtedly value in most “solutions.” However, a turnkey solution is not the path to the results an organization desires. Rather, the way to success is for the experts in the organization’s condition–its members–to understand their situation at the time they become ready to change. Then they can choose what helps with their actual needs. You should never change something just because someone says “that’s the way our solution says you must do it.”

It seems fairly simple to use the framework part of SAFe and not do a heavier than needed release plan. When the full degree of SAFe planning isn’t needed, perhaps because there are fewer teams or a natural alignment between the parts of the system being developed, we can adjust the planning event to be lighter. The key is to adjust the degree and length of the planning. The two-day SAFe planning event is just as much about socialization as it is about planning. Be sure to include lots of communication between the teams, even if you organize, for instance, with shared kanban boards and skip SAFe’s dependencies board.

Different communication mechanisms are needed at different scales. You will need to decide on the mechanisms you need at your scale. These kinds of conversations, though, create an opportunity to do SAFe in a lighter way than prescribed.  This enables us to get the holistic view of things without adopting anything overly heavy.

A major benefit that SAFe at any scale provides is a set of useful default management agreements. These address:

  • Managing workload
  • Preventing unwarranted interruptions to development teams
  • Requiring all teams to have the same cadence so that they can synchronize frequently
  • Running the teams in a test-first manner

A lightweight implementation of SAFe provides a framework within which to do Kaizen (small-step incremental improvement) to refine the structure of the organization as well as its management system.

The bottom line is that anything can be applied in too rote a manner…and this happens more often than not. Don’t just accept any prescription of a framework or method without first asking, “does this serve the needs my organization is actually experiencing?” If the answer is no, then skip the prescription; there are plenty of other prescriptions available for the needs you have without adopting any for those you don’t.

There are two ways to think of SAFe: as a whole template to which you conform your whole organization, or as a thinking framework with multiple practices that you can mine to address different development needs.

What Value Does the Middle Manager Add in Mid-Scale Agile?

Agile thinking emphasizes self-organization and personal initiative. We want these active in our organizations. However, when this emphasis is taken to an extreme it can imply that there is no place for managers. Some Agile leaders have even said this explicitly.

Lean-Agile, however, says that management and especially middle management has an important role in Agile. It becomes a force-multiplier for organizations in mid- and large-scale organizations. This article describes what middle management can do and how it benefits the Agile organization. Continue reading “What Value Does the Middle Manager Add in Mid-Scale Agile?”

How Can We Deliver the Most Value from Available Resources?

To produce the most value from your available resources in the allowed time, as soon as possible release first the part of the system that is truly necessary to have a viable business product. Restrict the time allowed for building this core part to only the time your estimates say it needs and don’t use all of the calendar time available.

This approach works with either kanban or Agile approaches. It is possible and simple to achieve a level of predictable work throughput and to do effective release planning. Continue reading “How Can We Deliver the Most Value from Available Resources?”

How Can We Release Innovation in Software Development? (Leveraging “Laws”)

Pendulums swing between extremes. Agile started out as a freewheeling movement in which there was little place for either management or for “laws;” i.e., cause-and-effect relationships like gravity-and-falling. Everything was to be invented by the “self-directed team,” which, it was assumed, would be more innovative as a result and would always end up doing things the best way. Continue reading “How Can We Release Innovation in Software Development? (Leveraging “Laws”)”

How Does Agile at Scale Increase the Delivery of Business Value?

Agile is often described as iteratively building software in increments. It is more effective to think of it in terms of being the incremental delivery of business value. Software by itself is not useful. Software that helps deliver business value is. The focus should be on the value to the business, not on the software. While we all know the importance of “time-to-market,” investigating how this relates in the software arena is particularly useful. Continue reading “How Does Agile at Scale Increase the Delivery of Business Value?”