April 18, 2014

All Posts Tagged With: Enterprise Agile

Agile Coaching Blog

Mind the WIP to Become Effective, Not Merely Efficient

Mind the WIP to Become Effective, Not Merely Efficient

“Efficiency is doing things right, while effectiveness is doing the right things.”

We’d all like to be efficient.  We’d love to show our boss how cheaply we can get something done, compared to all her other options.  We’d like to have extra time, maybe to clean up, beautify, or just goof around.  Efficiency is the hallmark of mass manufacturing.  If we build it for less, we have more profit to put in our pocket.  But did you ever consider that when we build software in situations where resources and dates are fixed that you’re making a huge, risky bet?  I venture to say that you’d rather ship 80% of your product features on a certain date (and have least valuable 20% left over for “the next time around”) than be 90% done on everything and have absolutely nothing to ship on that due date.

You probably have 2 questions at this point.  “How could that be?” and “How can I be effective, and not merely efficient?”  The answer to both questions is found in three tiny letters – WIP (work in process).

It all begins with estimation

Let’s take an easy example for this piece.  Here’s a list of things that we’d like to develop some software for and release to our new website in the next 90 days:

  • Allow website users to search for and display lists of items in our warehouse
  • Give website users the ability to display pictures and details for an item that they select
  • Give website users the power to display real time inventory status for an item that they are looking at
  • Give website users the ability to create a “shopping cart” of quantities of items that they select
  • Allow website users to complete a transaction and pay with credit card(s), PayPal, direct checking account, or any combination thereof

Assume that since we only have 90 days, the Delivery Team that we have, is the army that we will use. The 90-day window is non-negotiable, because we paid a zillion dollars for a Super Bowl ad that will drive traffic to our website on that fateful day.

If you’re a traditional, plan-driven project manager sort of person, you probably do this project by first decomposing the software stack into components that we’ll put together, and then create a project plan that pulls people, time, and dependencies together and convinces us that everything will be fine.

  • Database for the warehouse items
  • Component to access database
  • Website functionality for search
  • Website functionality for display
  • Website functionality for real time inventory
  • Website functionality for adding, displaying, deleting, and modifying items in the shopping cart
  • Component for integrating our warehouse system with the website real time inventory status
  • Component for implementing the shopping cart on the server
  • Component for credit card processing
  • Component for PayPal processing
  • Component for checking account ACH processing
  • Component for payment coordination between the various processing options

OK.  Got the list.  Get some estimates from various people.  Assign developers against the tasks.  Adjust estimates to make everything fit inside that 90 day window (Tell me that you’ve never done this.  Be honest!).  Announce “It’s going to be tight, but the plan demonstrates that we can do this.  So, let’s get going!”

With software, the odds of everything working in your project plan are a lot like your odds of hitting the Trifecta

But here’s the rub.  Estimates are made for things that we haven’t previously done.  We use our best effort to understand and give meaningful honest estimates.  And we do.  But the uncomfortable truth is that effort-based estimation for software construction is highly variable, due to a variety of factors:

  • Uncertainties with how to do things that we’ve never previously done.  For example, we’ve never tried to interface with our mainframe based warehouse system before.  We may find little nooks and crannies of problems and issues which we must solve to permit the integration that we never considered when we gave our limited “happy path” estimate.
  • Uncertainties around what things we should actually build.  For example, should that real-time warehouse inventory level stop people from adding items into their cart? Stop them from completing a transaction? Or just ask them if they want to place the item on backorder?  We’ve never done this with customers before, and we can’t be sure that customers will bring us enough value to cover our costs of development, since we’ve never before given customers this ability.  If we have to re-do a lot of work for a fully fleshed out feature, that could cost a lot.
  • Uncertainties based on who actually does the work.  Your best developers may be 10 times (or more) productive than your least capable ones.

And then we completely hide that variability in estimates by expressing a single number for the estimate.  The estimate, even though it is expressed as a single number, is really a probability curve.  It might look something like this:

Graph Source

And, finally, we completely compound and confound the problem by linking the tasks together with scheduling dependencies.  “We can’t start/finish this task before finishing/starting that one” (either because of software functionality dependencies or resource dependencies). Our project is a hope, wish, and desire that everything goes according to plan, even though we mathematically know that things will go wrong, and will start to cascade through the chain of scheduling dependencies.  If we start creating the compounded probability of arrogated estimates, we start to see that the nice peak on our bell style estimate distribution curve starts becoming very short and wide.  And our chances of hitting our estimate square on are about as likely as picking the “win, place, and show” horses, in order, at the track.

Yet somehow, seeing everything fit together in a nice Gantt chart that magically ends right on target makes us feel safe and sound.  At least when we start.  But without fail, almost every project plan that I’ve been around goes sour quickly.  One late dependency quickly snowballs into an avalanche of late tasks that just compound and worsen. Blame starts getting metered out.  Morale goes through the floor, and when we’re living the day before the game, we try to integrate everything, and nothing is working.  And now that the business sees the real time inventory status in action (when it sort of works) they aren’t sure that they want it, as they now realize that when people see that an item won’t be in stock for a couple of weeks, they may decide to go elsewhere!  But we’re so afraid that pulling out the code will break 20 things against the middle.  So, it’s part of the deployment, like it or not.

Gantt Chart

Our attempt to be hyper-efficient and get each and every feature working the day before the end suddenly becomes an #EPICFAIL when things don’t work on Super Bowl Sunday.

That’s horrible!  What’s a Mother to do? 

What if we turned this on its head?  Let’s say we start with a single ranked ordered list something like this?

  1. As a website user, I want to search for items to purchase using words in an item’s description, so I can find things to buy.
  2. As a website user, I want to display an item’s description, price, and primary picture, so I can decide if I want to purchase it.
  3. As a website user, when I click the “Buy It Now!” button on an item’s display page, I want a quantity of one item placed in my shopping cart so I can purchase it when I’m done shopping.
  4. As a website user, when I click the “Proceed to Checkout” button, I want my shopping cart displayed with checkout options.
  5. As a website user, when I click the “Purchase Now!” button with the “Debit My Checking Account” option clicked, I want an ACH setup to my checking account for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: this transaction is free through our bank.  Yay!
  6. As a website user, when I click the “Purchase Now!” button with the “PayPal” option clicked, I want my PayPal account to be debited for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 1% merchant fee on PayPal transactions.
  7. As a website user, when I click the “Purchase Now!” button with the “Mastercard” option clicked, I want my Mastercard account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 2% merchant fee on Mastercard transactions.
  8. As a website user, when I click the “Purchase Now!” button with the “American Express” option clicked, I want my American Express account to be charged for the amount due and the items in my cart shipped to me, so I can become a happy and loyal customer.  Note: we pay a 4% merchant fee on Mastercard transactions.
  9. As a website user, when I want to be able to change quantities and delete items in my shopping cart when I am checking out so I don’t get frustrated with a shopping cart that is not exactly what I want to purchase.
  10. As a website user, I want to display an item’s auxiliary pictures, to help push me to clip the “Buy It!” button.
  11. As a website user, I want to display an item’s real time inventory status, to help me decide if I want to buy the item now.  Note: the website user may decide to not buy the item when they see that it’s not in stock.
  12. As a website user, when I click the “Purchase Now!” button with the “Multiple Credit Card” options clicked, I want the ability to setup a complicated transaction [details to be thought through], so I can become a happy and loyal customer.  Note: we have to figure out technically what happens here, how to back out of scenario such as having one card going through and a subsequent card failing.
  13. As a website user, I want to backorder an item that real time inventory shows as out of stock so I can eventually purchase the item.  Making this happen will invoke a workflow involving eMails, order cancellation, and other things.

Notice what happens when we start to develop one thing at a time, in this order, and get feedback from the business as we complete each of these items.  If we got some of the details wrong (it happens all the time!), we can immediately get that right before we move on.  When the business says “Good!” on each item, we then get our deployment to stay “always ready to ship”.  If we run out of time, we may not have every feature completed, but we always have something to show on Super Bowl Sunday.  We’d like to get through the whole list, but we don’t even really know the details for some of this yet.  But we have enough to get started.

Untitled 2

What was different?

That’s easy.  We minded the WIP.

We made sure that we had the highest value items worked first, and did one thing at a time (“Single Stream Flow”, in Lean terms).  We were always ready to ship.  That allowed us to work right up to game time without fear that integration would ruin things.  We didn’t have to worry that we wouldn’t get to go home for the next two days, subsisting purely on Mountain Dew and day old pizza.  We concentrated on delivering value one step at a time, from most important to the least.

That pivot to focusing on business value, rather than figuring out the optimal plan that gets us to done can be a huge mindset change for some organizations.  Sometimes, managers are afraid that someone won’t have something to do when the team is working through the business value ordered backlog of functionality to create.  But remember, every time we add to our WIP, we create the potential that dependencies will keep us from being ready to ship.  We create the potential to very efficiently work on lots of stuff at once, but have nothing to show for it when the clock runs out. That’s not very smart.  And it’s awfully risky. It sure isn’t an effective way for your organization to work.

The prime directive is effectiveness – efficiency is only secondary

I don’t know how it works for your business, but for mine, I’d rather deliver 80% of the highest business valued items and leave the remaining 20% of lowest value items for sometime in the future.  I really don’t want to be 90% done with everything, but having nothing to show for it when the clock runs out, because that last 10% was needed to get anything to work.

For me, Meatloaf said it best, almost 40 years ago.  “I want you, oh, I need you.  But there ain’t no way I’m ever gonna love you. Now don’t be sad, oh, ’cause two out of three ain’t bad.”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

 

Share:

But It’s Just a Simple Matter of Coding – How Hard Could It Be?

Many times, I hear business people (such as Product Owners) bemoan how expensive software development is.  And the brutal truth is that for anything non-trivial, software costs a ton of money to develop.  I happened upon some numbers for a fairly simple but elegant iOS app called “Twitterrific”.  Twitterrific is a client to the Twitter network, uses a well defined interface created by Twitter, and does not require any backend development.  It runs on the iOS, which is a well defined, well documented, well supported, and stable environment for both development and use.  According to an article published on the PadGadget site, Twitterrific was developed by a single person (Craig Hockenberry) in about 1100 hours.  The article goes on to do the math at $150/hour, adds in design, testing, and so on, and comes up with a number of around $250K.  That’s just for labor.  No costs for a workplace, infrastructure, developer tools, and so on.  Once you start adding in enterprise costs for offices, management labor, etc., and start building multiple tier complex applications, It’s easy to see why business people would look at the finished work (knowing how they interact with computers, which has become easier and easier over the years) and wonder “How hard could it be?”

That burning issue perplexes many organizations.  It isn’t usually an issue with companies with disruptive products – when margins are huge, things become profitable quickly and easily.  It isn’t usually an issue with a young, well funded company – if there is a long enough runway covered in money, and you aren’t accountable for showing profits until sometime far down the road, costs are not the issue.  However, it is a huge issue in many enterprise IT settings, where capitalized expenditures are rigorously scrutinized to see what work can be done under the funding constraints that exist. So, why is software such an expensive thing to create?

Here are four reasons that I find compelling.

  1. For anything other than trivial software, the potential for failure due to complexity and development risks is huge.  Back when mainframes ruled the earth in the 60s and 70s, the average program was thousands of lines of code. Today, it is very common to see applications that are tens of millions of lines of code. And, since any line of code can potentially affect any other line of code through side effects, a program that is 10 million lines of code is one million times more complicated than a program that is 10 thousand lines of code (a so called “n squared” problem).  The care needed to create code that works at all, and the potential to have bugs emerge is astronomically high.  While we have better tools now than we had forty or fifty years ago, they aren’t a million times better.  Trust me!  I developed software on machines back then as well as now.
  2. Programming is more like an art than it is engineering.  Engineering and building large and useful things on schedule has become commonplace nowadays, and people count on it.  For example, Tommy Lennhamn (from IBM), states that “Examples of successful engineering projects, at least with respect to schedule, are all the construction projects for Olympic Games — as far as I know, all Olympic Games have started on time, on fundamentally new premises.”  The secret is that with engineering problems for things like constructing buildings, components to build from are well known, assemble together well, and don’t create too many unknown side effects when bolted together.  In that type of situation the hard part about the project is agreeing on what to build.  With software, many times the business doesn’t know what to build until they build something to see if it solves the problem.  But that operates in a doubly damning world where developers don’t have the components that assemble together without knowing for sure if their construction in one place has affected something else (and someone else) in the code base.  Not withstanding the efforts of TDD, we can never prove correctness in software to the same extent that we can with mechanical construction.
  3. Not all developers are created equal.  The barrier to enter the field is relatively low.  This attracts a lot of people to compete for relatively high paying jobs.  But, as people like Steve McConnell point out (in IEEE Software, Vol. 15, No. 2), “…differences of more than 20 to 1 in the time required by different developers to debug the same problem” exist.  Does it make more sense to hire one awesome person for $200K or 10 mediocre people for $90K each?  Remember, once you hire 10 people, communication issues will slow you down (Fred Brooks “Mythical Man Month” stuff, but I digress).  While there may be a glut of cheaper labor today relative to the salary requirements of the awesome developers (due to such factors as geographic outsourcing), the reality is most enterprise IT settings would never hire the really awesome developer at a relatively high pay grade, due to political issues. And, even if they could, they would be hard pressed to find talent willing to work in the stodgy environments that many enterprise IT settings have become.
  4. There is still a wall of disengagement between business and development that needs to be broken down.  The Agile movement of the last 13 years has done a lot to publicize the need to have “Product Owners” engage on at least a daily basis (with continuous engagement being the best), but it is still very common to see business people physically and geographically separated from development.  Worse yet is when enterprise business people complain about how much “more important” work they have to do, and how they yearn to return to the days of yesteryear, when they could ask the Project Manager for a status update, and then complain when things were behind schedule.  Lean thinking tells us that faster feedback loop cycles will create less waste, and therefore more and better product.  Given the realities of 1-3 above, and the cost associated with those items, I implore such business people to stay with the development teams and help them help you reach the enterprise’s goals.

It’s a shame that software is so exquisitely expensive to make, as the opportunities to enrich our lives by using relatively cheap hardware is everywhere.  Everything from smart thermostats (such as the “Nest”) to smart light (such as the Philips Hue) to truly personal computers (such as Samsung Galaxy Gear and Google Glass) surrounds us.  And it all takes programming computers in one way, shape, or form.  Unhappily, programming computers is anything but easy.  But if you consider that humans have been building houses, roads, and bridges for thousands of years, and are still faced with colossal failures from time to time, it sort of puts things into perspective.  Programming will continue to evolve into something more of an engineering practice someday, and programming may eventually become something relatively simple.  Of course, we’ll have to find something else to complain about if that ever occurs!

Kinky for Governor Poster

Kinky Friedman ran for governor of Texas in 2006 on the slogan is “How Hard Could It Be?” While this was a great line, no one, including Kinky himself, ever believed it. Even Kinky admitted that “I’ll hire good people!”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

The Essence of Agility: Becoming Safer by Controlling Less

The other day, I presented at Agile India 2014 on the topic of “Pivoting Your Organization to Become Agile Testers”. Near the end, when I was tying up all the points in the talk, I was speaking about wastes that come from “big batch thinking” and gave an analogy off the cuff (and way off my talking points!) to illustrate why the most useful testing should be automated at a product functionality level.  The analogy I conjured up is powerful, and is an application of lean thinking that has value in so many enterprise-type organizations.  The basic message is that by planning less (not attempting to not try to preplan so such about how things will work, but instead concentrate on showing that things actually are working) and lightening up on process controls, we can gain a lot in the sense of getting actual stuff done, and not just measuring the busy work that accompanies getting that stuff done.

The analogy I used has to do with cars and the flow of traffic.  It starts with the 20th century concept of separating drivers from pedestrians, which was developed to keep pedestrians safe from fast moving cars and to allow cars to be driven without constantly fearing that they might run into pedestrians.  As wider and faster roads developed, the need to use road signage and traffic signals to control the flow of movement became both an expectation and a necessity.  But the traffic signs and signals had an unintended consequence.  Drivers felt that if they simply obeyed what the signs told them that they were allowed to do, they could be safe in just driving and not have to worry about the current conditions or how they needed to react to them.  Some people slowly began to question these assumptions.  For example, Hans Monderman, the Dutch road traffic engineer behind the Drachten Experiment (more about that in a minute), has said, “A wide road with a lot of signs is telling a story.  It’s saying, go ahead, don’t worry, go as fast as you want, there’s no need to pay attention to your surroundings. And that’s a very dangerous message.”

An interesting way of “seeing” the issue of inattention when concentrating on a task at hand is to experience “The Monkey Business Illusion”.  Take a minute to try the YouTube video and play along!

)

Are you back?  How did you do?  Think of how this applies to driving, and maybe even some close calls you had when driving.  When our attention is on task to do something specific asked of us, such as “Count how many times the players wearing white pass the ball”, or “Speed Limit 50 MPH”, we can easily lose the bigger perspective of very important things.

Anyhow, back to “The Drachten Experiment”.  Drachten, a Dutch town in the Netherlands, is an old medieval city that has been growing steadily in the past 60 years.  The town had a problem that it wanted to solve.  It wanted to lessen downtown traffic congestion and reduce traffic accident rates at the same time.  For 100 years, the accepted way to accomplish this has been to separate people and vehicles, introduce road signs and traffic signals, and have strict rules on who has the right of way and when.  But the town had enough of that school of thought, and felt it could go better by doing something which seemed weird at first glance.

What Monderman did for Drachten was to remove all of the traffic lights and road signs from the town’s center.  This had the effect of reducing accidents from about 8 per year before the experiment to about 1 per year after the experiment.  Throughput, even in the face of additional traffic numbers, has increased with average measured delays reduced from about 50 seconds to between 10 and 30 seconds.  An explanation of the reduction in accident rates is that many drivers habitually race through traffic lights right before they turn red.  They get lulled into a false sense of security by the confidence that they have right of way – making them less aware of potential hazards, such as people that are anticipating the changing traffic signal and ready to assert their right of way.  Perhaps you can recall an experience like that.  It usually evokes pangs of anxiety as we think about what could have happened.

Drachten before Hans Monderman.

 

Drachten after Hans Monderman.

The trouble is that we have the same sorts of issues when we do traditional project management.  We preplan the dependencies, map out what the expectations for what final integration will be, and then start reporting on how close each sub-project is towards the ultimate goal.  We install our own forms of traffic signals, called “gates” in traditional project management, and have fairly high ceremony events, using terms like “go / no go” decision points.  In our zeal to track and manage progress towards the ultimate goal, we can be blinded to the actual problems facing the project.  The false security that we get from showing progress against the plan, by using the process we employ, can blind us to the fact that a gorilla has come on the stage, that the curtain has changed color, or that our car now poses a treat to a pedestrian entering the cross walk.  Successful projects don’t get that way by just being right on the process.  They have to pay attention to the right things that change, and make sure that the relevant issues are surfaced as quickly as possible to avoid last minute close class (or worse!)  Letting go of some process gives much better results than rigid control of flow.  That’s what agile planning is all about.

Lao-tsu, in the Tao Te Ching, said it best:

Stop trying to control. Let go of fixed plans and concepts, and the world will govern itself.  The more prohibitions you have, the less virtuous people will be.
….
If you don’t trust the people, you make them untrustworthy.

We hire good people to work for us.  We owe it to them to trust them to do the jobs they were hired to do.  As leaders, it’s our job to ensure that the organization is configured to allow that to occur and that there are as few road signs and traffic signals as we can get away with.  We don’t need false senses of security.  We need results.  Reduce the control points down to where people act as people, see the whole picture, and can act appropriately.  That’s the essence of agility, and where we need to be.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.

subscribe

Share:

The SAFe Framework: Rigid & Prescriptive? Or Adaptable & Evolving?

SAFe: Rigid & Prescriptive? Or Adaptable & Evolving?

The Scaled Agile Framework (SAFe) is a hot topic in the Agile community these days. The Coaches and Consultants at BigVisible, like many elsewhere, have been debating the pros and cons of the SAFe framework for a year or two now. We’ve attempted to dispassionately compare and contrast results from our experiences rolling out SAFe at clients who requested it, to the results at Agile transformations done “The BV Way” in large enterprises over more than a decade. While specific differences between the approaches will be addressed in a later edition, let’s begin by examining common objections to SAFe, and considering their validity.


If you are new to the Scaled Agile Framework, start here. For information on the BV Way, contact BV or start here.

Constructive criticisms of SAFe usually address the apparent prescriptiveness and comprehensiveness of this intricate integrated framework.

These criticisms are based on the proven principles that:

1. Organizations are complex systems that evolve their optimal practices and structures as a result of observation, experimentation, and learning over time. One-size-fits-all solution frameworks can’t be as effective as self-tailored solutions evolved organically, nor do they teach the organization to learn and adapt, a critical capability.

2. Change “sticks” when buy-in and ownership of new practices and structures result from shared observation and learning; when new ways of working are developed by those doing the work.

3. People tend to underestimate the complexity, difficulty, and importance of change-management when you can just “buy” an “off the shelf” process framework. The appealing illusion that meaningful change can be prescribed in a nicely packaged graphic may actually diminish the likelihood of successful change, because organizations fail to embrace the commitment and investment necessary to implement change in large organizations.

4. The importance of leadership styles and the need to evolve legacy organizational cultures can be overlooked when one can just “implement a framework”. The foundations of Lean and Agile depend, above all, on the investment in, and empowerment of, people.The critics presenting these arguments correctly emphasize the tremendous value of having experienced coaches and consultants guide organizations through the journey of discovering and adopting new ways of working to implement successful and lasting change. Unique improvement objectives and business and cultural environments produce unique solutions.

These criticisms of SAFe emphasize some very important points, but they assume a dichotomy that doesn’t exist. They imply SAFe’s sponsors disagree,or would knowingly advise a client to underinvest in change management and self-discovery as a basis for continuous improvement.They present a straw-man argument that implies 1) the framework is intended to be implemented verbatim in its entirety, irrespective of context, and 2) that there is no need for a professionally managed change-management initiative to successfully implement SAFe in a complex enterprise. In my interactions with the SAFe community, and my experience becoming a SAFe Program Consultant, I have observed that the SAFe community values and supports:

• Encouraging organizations to inspect and adapt the way they work and support continuous improvement, to include customizing SAFe

• Engaging coaches and investing in the sponsorship and structures to support successful change management

• Embracing leadership and culture as crucial to any significant organizational improvement

Perhaps these points should be illustrated and emphasized more forcefully in the SAFe literature, but nobody I’ve met in the SAFe community is denying their importance.We have established that there are risks to providing too-pat answers to complex organizational challenges. Are there benefits from the SAFe framework’s comprehensive and prescriptive appearance? My experience is that there are.

For example:

BigVisible has observed that large enterprise clients often doubt their own organization’s ability to change. They reject case-studies because their challenges are “unique”, but often demand an illustration of their Agile end-state. Responsible coaches answer that a client’s future state will be emergent and non-deterministic, but the SAFe framework provides value because it helps clients see one concrete instantiation that probably supports many of their critical functions. SAFe’s clear and seemingly complete organizational archetype of Agile for large complex organizations reduces fear and trepidation. By illustrating a rich set of patterns proven effective in large enterprises,SAFe provides people confidence that they don’t have to invent every element themselves.

SAFe also provides an implementation template for getting a “release train” of teams rolling with a solid release-planning model. Giving clients confidence that SAFe is built on tested and proven structures that large complex enterprises have implemented successfully gives them confidence to move forward more aggressively. Many of us in the coaching community have long espoused release planning as crucial to program-level effectiveness. My initial reaction was that SAFe advocated release planning at an earlier stage of team maturity than I was comfortable with.In practice, though, I have observed the SAFe approach work as a forcing function to dramatically accelerate line-of-business planning,improve communication, and aid cross- team alignment. Like any pattern language, SAFe allows us to streamline communication and “get to the meat” of our process and structure debates by starting with a universally understood standard. Using known templates as a default or a position to offset from, helps us shortcut poor time investments, so we can focus our efforts on areas that reward innovation. I hope some of the points above have helped illustrate some of the risks of misusing a framework, as well as providing some practical insights to where and how SAFe has real benefits to large organizations attempting to scale Agile. Like any good craftsman, we have a wonderful variety of tools in our consulting toolbox.

I’m convinced that in the right setting, used by the right hands, SAFe is a tool that can provide great value to enterprises. In the next installment, we’ll emphasize the basics to have in place for successful scaling; the foundation of team practices and structures essential to support the scale and complexity addressed by the program and portfolio levels of the SAFe Framework.

Want more SAfe Framework Implementation Tips & Techniques?Join us for our upcoming webinar on December 13th, 10 a.m. PST/ 1 p.m. EST

“Hit the Ground Running: Design and Manage Your SAFe Implementation”

BigVisible Webinars CTA

Share:

The Great Wall: Scaling Agile on a Multi-Team Project

If you are launching a large-scale agile project (e.g. one that requires more than a couple of Scrum teams) then careful consideration should be given to how you scale the management of the project. Starting off by applying standard scaled agile management solutions (i.e. Scrum of Scrums or SAFe) may help you feel like you are getting off to a good start. However, with those solutions comes the danger of creating a management structure that focuses on optimizing the project structure primarily for management’s benefit rather optimizing the project’s structure for the delivery of a valuable, usable and feasible solution.

This paper describes a lightweight yet powerful approach to scaling agile management for a multi-team project. ‘The Great Wall’ is an approach that enables the emergence of a scaled management solution that focuses first on promoting the delivery of the solution but also satisfies the needs of management.

Get the full article!

Scaling Scrum – BigVisible

Share:

Sense-and-Respond: A Broad Organizational Capability

In order to avoid the pitfalls of myopic agility, it can be helpful, if not downright prudent, for you as a leader to broaden the lens through which you think about the very notion of agility. You want to move your thinking beyond just teams.

I invite you to think of agility in the following most general, most widely applicable terms:

Agility is the capacity to effectively sense and respond to—and ultimately shape—events, situations, and conditions in order to enhance a system’s (individual’s, team’s, organization’s) ability to thrive in ever-changing environments and conditions.

Let’s first examine the key terms sense and respond and then turn to the implications for managers and leaders who wish to bring about a broader, organizational agility.

Sensing

Agility & Sensing
Sensing means having acute and accurate awareness of what’s going on. Often, however, filters exist which either obscure or distort reality. Common examples include: [Read more...]

Share:

Rise of the Lean Executive

“No institution can possibly survive if it needs geniuses or supermen to manage it.” – Peter Drucker

Drucker has passed on, but fortunately for us his ideas have not.

Corporate executives are turning to books like The Lean Startup for ideas on how to keep their organizations relevant. (I know because I see the growing demand for it in our work)

Lean Executive

They are frustrated and under an enormous amount of pressure. Not only do executives have to worry about other large and mid-sized companies, but now even startups, seemingly come out of nowhere to take away market share.

Executives are discovering it isn’t enough to encourage practices such as building Minimum Viable Products to create meaningful change in their organizations.

Smart executives realize that to win the game, their organizations need to discover, learn, and act quicker than the competition.

I call these executives, Lean Executives. [Read more...]

Share: