Lean Agile | LeanOrange

Are you the magic?

May 2, 2013 — Leave a comment

i-love-cartoons.us

Lean|Agile coaching should be like high octane fuel for organizational engines. They should help organizations go faster and help achieve maximum performance through value delivery.

However, they should not be the magic. They don’t do the engineering. Good coaches really provide the spark to get the train moving and the guidance to keep it on the rails.

If you are the magic, it can be very rewarding. However, you are actually a parasite to organizational health. Why? Because you are building internal dependencies on yourself. When you move on to your next engagement after success has been claimed, the floor will drop out from beneath your previous client. FWIW…you don’t have to be a Lean|Agile coach to be the magic. You might be the next diva developer.

I’m bringing this to light because I have been that person. I don’t say that pump more air into my head. Its easy to say yes and take on challenges you feel equipped to solve. What’s harder? Saying no and mentoring! Having the courage to encourage and teach someone else to be as good as you or even better!

Better? Yes even better than you! This might seem like a threat to your self preservation, but after all, if you’re a consultant you get paid for short term assignments. If you can prove yourself as a worthy coach and mentor, you will work yourself out of your current job. But, you will work yourself into so many opportunities you will be forced to say….wait for it….NO!

So be vulnerable. “Open source” yourself to your clients. You just may become the next Roy Fielding or Doug Cutting!

In Lean Agile

Second Generation Agile

April 11, 2013 — Leave a comment

family

Over the past few years we’ve heard some of the thought leaders in the Agile community start referring to “second generation” Agile methods. Most notably among these thought leaders are Dean Leffingwell and Al Shalloway. While there are many others, these two leaders have writing, teaching, and implementing these second generation methods. Its no surprise that they are principle contributors to the Scaled Agile Framework.

Second generation Agile methods really refers to Lean|Agile methods. Agile had tremendous success as delivering high value(PO – thx Scrum), high quality(thx XP) software rapidly. However the typical context was across a small group of teams(< 50). The industry is now scaling these efficiency gains to the enterprise. We are now building systems with hundreds and in some cases thousands of people. Our context has changed and our methods are changing to meet the demand. This is where the phrase Lean|Agile is rooted.

Lean|Agile methods are rooted in Lean. What does that mean? Well that’s a long story. We recommend reading two books to get an understanding of Lean. First The Toyota Way(history/origins of Lean) and second Principles of Product Development Flow(Lean principles for product developers) by Don Reinertsen. The latter is an extremely tough read because it is just a set of principles and you have to bridge the gap to application. However really provides the foundational principles of Lean applied to product development that big enterprises desperately need to make sense of why Lean|Agile practices work. It also helps us reason about solutions to really hard problems we encounter day to day. I guess you could say its “True North.”

The Scaled Agile Framework(SAFe) is built on Lean and applies many of the principles from Reinertsen’s book. For instance, SAFe is driven by Reinertsen’s economic principles. It largely does this by applying Weighted Shortest Job First(WSJF). Why is this important? As enterprise frameworks and methods plow into larger and larger enterprises, the complexity scales exponentially. Lean scales as well. It’s the language of business. Best of all for agilists, agile practices are aligned with Lean principles. For instance backlog wish lists allow for shallow queues and cross functional teams allow for small batch sizes.

So simply enough, as we bring agility to enterprises we need to change our toolset. Second generation Agile methods…aka Lean|Agile methods provide the toolset that allows agility to scale. We recommend checking our the Scaled Agile Framework(SAFe) to learn more about these methods because it is not only rooted in Lean principles, it applies them as well using Lean and Agile practices. Enjoy!

In Agile, Lean Agile, Scaled Agile

Rebaselining for Agile at Scale

April 4, 2013 — Leave a comment

small-gun-ship

Let’s face it, technology systems are getting bigger and bigger. Big data systems have moved beyond the lab and entrenched themselves in today’s market place as viable value drivers. These systems and their supporting ecosystems are extremely complex. They are more like aircraft carriers than small gun boats! To build large, complex systems we (the software industry) need to refactor our product development practices.

We often see the following pattern when large (50+ people) programs kick off. Their energy and enthusiasm to use cutting edge technologies drives them towards more modern development practices. That is Agile practices. Unfortunately, they usually try to apply low complexity Agile frameworks and practices to their high complexity environment.

What does that mean? Our experience is they try to apply Scrum and a select few XP engineering practices to manage and deliver their system. Inevitably, this breaks down for a variety of reasons and they revert back to BUFD, Waterfall methods. #FAIL

Their approach to organizing and managing delivery at scale was flawed from the start. We need tools and practices that map to high complexity environments in order to realize value at scale. While Scrum is part of the solution, it is not the whole solution. Its our opinion that the Scaled Agile Framework (SAFe) is currently the best and most mature tip revision of our industry’s current thinking to deliver at scale.

Here are some SAFe practices we must rebaseline when scaling agility:

Product Owners don’t have complete autonomy anymore. They must work from the program backlog that is managed by Product Management. This is necessary to bring value alignment across the whole system.
System designers don’t have complete autonomy either. They must work within the constraints of the enterprise architecture. Otherwise significant refactors will cause poor economics.
- Note – Agile Architecture is significantly different than traditional ivory tower, BUFD architecture.
Continuous Integration must occur at the system level. Since these systems realize value at the system level, system level CI practices are necessary.
Local team demo does not equal system demo. Demos must scale to the system level on the same cadence as the teams so that our system stakeholders can provide valuable system level feedback necessary for maximum agility.
Quality can’t be built in later. Software quality breaks down exponentially as systems scale. Just one system component with substandard quality can bring the whole system to its knees. To maximize the economics(agility) of system development, we can’t wait for a refactoring sprint. Quality must be built in as we develop across every team!

In Enterprise Agility, Lean Agile, Scaled Agile

Hypothesis Driven Development(HDD)

February 8, 2013 — Leave a comment

We came across this picture while writing the Agile C’MON Man post. The irrational exuberance in this picture gave us a chuckle, but it also reminds us of an engineering group driving product development. As we articulated in the previous post, engineering driven product development can lead to BUFD. At the same time, we articulated the lack of business driven product development is due to ill equipped product management. In this post we will lay out a high level business approach to product development.

We think this is the new frontier for Agile and software development. The Lean Startup and David Joyce’s talk, 21st Century Portfolio Management, are great resources to start shaping how we need to think about driving product development. The fundamental principle that these two resources drive home is learning. Our ability to deliver higher value products hinges on our ability to learn. These resources also champion the fact that learning on the business side does not end after a business case has been delivered, nor after requirements captured, nor after a team has showcased working software at a demo. No, learning needs to happen with real customers. Therefore, we need to consider how we are going to learn throughout the whole lifecycle, including customer consumption.

Learning_Adoption Learning is not a new concept, especially when we talk about feedback loops in SDLC’s. However, the difference here is the measured approach to learning. We should not just ask what should be built, but why it should be built. Therefore, we should wrap measurements by which value returned can be measured and validated. It is this process of being intentional about quantifying results based on predetermined measures that helps accelerate learning. Documenting measures that align to our assumptions, force us to gain a deeper understanding of why our customers want what they want.

Experiments – You may have heard these forward leaning thinkers refer to this process as “running experiments.” At face value, this conjures up thoughts of lab rooms and scientists, but we’re doing software development…right? Well think about it. If we’re making assumptions and documenting what to measure after a capability has been delivered, it’s safe to say that this sounds like a hypothesis. If we build out that hypothesis and then measure the results, we essentially are running an experiment So it’s not that crazy after all.

Recently, a new “xDD” (x Driven Development) has hit the radar. Hypothesis Driven Development(HDD). Its so new, that there isn’t even a Wiki page for it! Mind blowing…I know! Whether you call it HDD, Lean Startup, 21st Centrury Portfolio Managment, or whatever, we think this is an area business product developers can gravitate towards to build better products. If you have thoughts to share on this topic, we’d love to learn with you! Please comment or DM us to continue the conversation.

In Business Driven, Continuous Delivery, Delivering Software, Lean Agile