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
permalink

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
permalink

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:

  1. 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.
  2. 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.
  3. Continuous Integration must occur at the system level.  Since these systems realize value at the system level, system level CI practices are necessary.
  4. 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.
  5. 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
permalink

Lean Orange Announces the CLOP – Certified Lean Orange Professional

April 1, 2013 — Leave a comment

shutterstock_13984771

 

We are excited to announce the next big thing!  Wait for it…the CLOPTM – short for Certified Lean Orange Professional.

Pronounced C-L-O-P, not KLOP or SeeLop.  We’ve trademarked the pronunciation as well.  This is very important because it was statistically proven that those that who pronounced the S.A.T. test as S-A-T, performed better on their exam.  We want to be associated with high minds and high performers.  So for the sake of maintaining a premium brand please use the trademarked pronunciation.

The background

We have learned over the years that developing and delivering software really isn’t that difficult once you understand the principles and practices.  So it would make sense that if we could package up all the goodness that those who have gone before us have learned, pour cement on it, and share it with the world, we could change the software industry forever!  We would never have experience software failures again.  That is our mission and goal for the CLOPTM.

The details

What:  The  CLOPTM is a 20 year immersive program that teaches you to become an expert in

  • Computer Science
  • Systems Engineering
  • Enterprise Architecture
  • Data Science
  • Graphical Design
  • Quality Assurance
  • Process Improvement
  • Product Management
  • Project Management
  • Behavioral Science
  • Executive Leadership.

Where:  The  CLOPTM campus is in the heart of Silicon Valley.  This location gives us direct exposure to the cesspool of mediocre product developers who are considered the cream of the crop today.  This location will also allow our students to realize their competitive superiority in real time!

Cost:  The  CLOPTM pricing model is as unique as its name.  There is no, I repeat no charge upfront for the program!!!  Instead the CLOPTM council will get a 5% royalty from any earnings that students make for the rest of their life.  This aligns with our belief that in 20 years, students will be so far ahead of the competition, there will be no competition.  Its a more secure investment than a Greek bond.

We look forward to our first graduating class in 2033!!!

In Agile, fun
permalink

Business Driven – Value Streams

March 14, 2013 — Leave a comment

shutterstock_16658554

Value Streams

First we need to take a step back understand the business you’re program, portfolio, or enterprise is in.

Your business can be described as a set of business outcomes we call value streams.

We describe value streams as programs that are in place to achieve or extend a business outcome.

Each value stream may have several application areas that support the delivery of end user value.  Important: shed any application specific references from this discussion.  Being business driven means just that.  Focusing on the business objectives and the set of outcomes necessary to achieve those objectives.  Therefore, programs are stood up to drive business outcomes through a given value stream to achieve a business objective.

SMART Objective

Business programs should have a clear, dare I say, SMART objective that business outcomes align to.  – Increase leads by 20%.  Reduce production cycle time by 50%.  Without this, a business program will be spitting in the wind when determining the set of necessary business outcomes…if they do at all.  Ultimately its, these business outcomes that define releasable chunks of value often referred to as MMF’s, MVP’s, …etc that make up your business program backlog.

Agile Business Planning

A note of caution, we’re not suggesting a big, upfront, business planning session and then pouring cement on those business outcomes that align to a strategic business objective.  Achieving value through productive development is a highly uncertain process and requires adaptive business discovery and delivery practices.  So its a given that we expect business needs to change as the market evolves.  However, once we understand a program’s business objective and outcomes can put the set of adaptive business practices in place needed to drive value through our IT service providers based on business needs.

In subsequent posts we’ll dive into discovering and prioritizing business value.  Stay tuned!

In Business Driven
permalink