Archives for posts with tag: Big Visible Solutions

Must interrupt regularly scheduled TGIF interview about the recent nonprofit development sprint to bring you the following, just published by Mind Edge, learning in innovation (based in Waltham, Mass).

Cheers, and make sure your weekend ROCKS!

Devin Hedge is an Agile Coach with Big Visible Solutions, and is now coaching one of the largest financial management firms in Raleigh-Durham.  He agreed to be interviewed for “TGIF,” our Friday custom of seeking out choice bits of thought exchange.  MANY THANKS to Devin, who can be reached through his website ( for feedback or inquiries.

AB:  So we’re speaking today about working environments  in which the impetus for adopting Agile does not come from the top down.   Have you witnessed this phenomenon of Stealth Agile?

DH:  I would say 99% of the impetus for adopting Agile is grassroots.  A small team within a software development or IT shop is fed up with bureaucracy and the typical way things get done, or rather don’t get done.  Agile compelled me in this way, that’s where I started.  Going back to 1997, all the Agile teams I worked on, they were all stealth.   We dumped the traditional project plans, we dumped the Gant charts.  We looked around for other models.

I was working in the European telecommunications industry, in which many countries were just starting to transition to free markets, it was scary for them, times were uncertain and we needed to be able to deliver value quickly.  [DBH] I started as a staff developer but quickly became a Team Lead once they realized that I had a leadership background as an Army Officer. I started looking around for all sorts of ways to turn a chaotic situation into delivering what our business partners wanted.

I had learned about doing stand-ups from an article in a pop-management magazine about lessons to be learned from a Navy boat commander.   He would have stand up briefings at the beginning of the day.  This got everyone focused on the same things.  The article pointed out that the Command and Information Center had big visible charts all over the place. It put all of the  work happening on the right out in front of the whole team.  The Navy has been that way for years, whether you’re on a destroyer or a frigate or an aircraft carrier, there are big glass walls where they would put everything.  That way the commander or captain could – at a glance – gain complete situational awareness. It was also a way for each of the officers to hold each other accountable for getting things done.

This really resonated with me because as an Army NCO and later as a young Officer, I spent time supporting a lot of elite forces. There was a team dynamic there that I was going for. I knew these kind of teams could exist and be highly productive because I had seen them in our government. These were self-contained teams, close knit and cross-functional. When I applied the same principles to software development teams, it all just clicked.

I started having standups, set up the big charts on the wall and then asked, “What we could show after one week?” By the end of one week we were able to turn a prototype back to the customer and ask for feedback.  We didn’t get much sleep, but we were wildly successful. If kinda snowballed from there once the customer was able to see and touch the software early on. After that,  I was asked to be a the project manager for 30 guys and gals on a one month sprint.  After that, it was a distributed team, spanning the UK, Australia and India.

As a Project Manager, I started to have a cult following.  This was not because I walk on water (obviously!) but because, when you put people at the center of the process, everything works.

AB: What is it about Agile that attracts workers on a stealth basis?

DH: Quality stays right out front the whole time.  Good quality assurance programs try to harmonize the fact that you can meet every specification, but if the market rejects it, the product isn’t good.  We know that having two truckloads of documentation at the end of a process is not actually proof that a product was good.

One thing about quality, it’s in the eye of the beholder, just like beauty.  Many quality implementation frameworks end up transforming something that was well-meaning into a check-the-box exercise instead of actually looking at the product.  It should be more like an art critique.  Agile just does that naturally, through tight feedback loops.

Most small teams like Agile because it fires up people’s creative juices.  We are not robots; we are not here to do the same repetitive task over and over.  We are here to do a unique task that is highly nuanced – singularly unique every time – based on human experience.  That’s why Agile is so appealing to knowledge workers who should have been hired for creativity, for situations in which what is required is kind of fuzzy.  It enables the human potential within them to come out, expressing the intrinsic value of work.

Agile has all sorts of built-in reward systems.  Computers give us interesting puzzles to figure out.  The problem is, if you’re the only person who plays with the puzzle it’s not that rewarding.   Someone else recognizing what you went through to produce that product is a self-reinforcing reward system.  Agile recognizes people’s mastery.

AB: What happens when a Stealth Agile team tries to scale up?

DH: A couple things.  When you first start adopting Agile outside the initial hive, we often see “teams” that aren’t acting like cross-functional, self-organized, empowered teams. Instead we find groups of individuals. Part of this is the Gulture Culture of celebrating being an Introvert. Nothing wrong with that. However, we need teams. So, the Introverts who aren’t used to collaborating very well might resist getting dragged into a team. Usually the objections aren’t real objections, they’re expressing insecurity about some facet of the process. Takes a little digging to figure out what’s really going on. A command-and-control culture might say that the person has “issues” or “lack of skills,” expressing a judgmental attitude.  That is rarely true. Often the situation is that the Leadership Style being employed just hasn’t found the right way to motivate the person. In Agile we take the time because people are more important than process.

Also, to scale out of being Stealth, you have to create an environment where it is safe to fail.  I’m not talking big failures, but lots of little ones that don’t cause any real harm, the kind people actually learn a lot from.  Christiansen in the Innovators’ DNA talks about how safe environments help workers connect their synapses by asking probing questions, personal networking with others, and taking time to observe in and out of the company.

In Stealth mode, it is easy to create this environment. You’re in an isolated bubble. At some point, Stealth Agile starts to gain what I call “viral velocity” and the team hits a wall when it can no longer be stealth. You have to explain why you’re not doing such and such documentation of where you have failed forward as a learning opportunity and someone just sees it as failure.  Generally there’s someone in middle or upper management who just doesn’t understand. This really isn’t because of process or policy. It is because the culture inside the Stealth Agile team is so different from the larger organization around it.

So you have to find your champion and your change agent.  We’ve found that having a group of at least four people, two supportive people at two different levels in the company, is a critical factor for getting past this culture shock to the organization. There is real Brain Science at play in the way people will resist the Stealth Agile team joining the rest of the organization.  The basal ganglia part of the brain is always searching for pattern recognition.  A response to the new and unfamiliar can override reason because it triggers flight or fight.  In situations where you’re trying to expand out of a Stealth Agile team, the rest of the organization doesn’t have a “pattern match”, so the champion and change agent have to create the experience, the pattern match, that helps click pieces into place horizontally and vertically through the organization in order for the new culture to stick.

The message from the Stealth Agile team to the rest of the company should be two-fold.  First, they should communicate the story of their pattern of responding and adapting to rapidly changing business needs.  The strength of the feedback loop created through close customer collaboration creates a narrative all by itself which then becomes compelling to the champion and change agent and gets retold.

The second part is management seeing the potential for what happens if the company embraces Agile outright.   At a very personal level, you have to activate the senses of management: desire gets triggered and then fulfilled just the way it does in a user story.

There is a hitch to all of this. There have to be structures for fulfillment around the Stealth Agile team or group or department otherwise there’s no survival at scale.  So you have to create a lot of buzz  around how much return on investment you’re going to get by being able to adapt and quickly respond to changing business needs, to ensure that the requisite structures are in place to be successful.

It’s management’s job to push, see how hard they can push people. That’s their job. It’s how they do that in the culture that matters.  There’s a directing style of leadership and a servant or motivating style of leadership.  The latter recognizes that people aren’t typically motivated by someone dictating policies.  Stealth Agile teams need to trigger a larger desire within the company for a different way of working and then fulfill that desire.

What is Agile?

As the arts community agrees on the value of entrepreneurship, one specific framework to look at is Agile.  Originating from within the fast paced, ever-changing world of software development, Agile is now spreading to other business sectors, even outside of the start-up community.  Big Visible Solutions is one company offering regular trainings in New York City in a form of Agile known as Scrum, which offers enough reference points to make it an arts-friendly way to plan, organize workflow and manage teams.

Planning in Agile Mode

A traditional planning process is geared towards envisioning the entire plan from start to finish prior to execution.  One of the assumptions made is that the conditions which govern the operating climate at the start of the planning process will remain stable throughout the period covered by the plan.  Alternatively, a five-year plan may be drafted with the assumption that it will need to be examined and revised each year in order to remain relevant.  That’s an awful lot of time committed to be spent planning!

Agile planning mode is more reality-based.  It assumes that you cannot possibly know everything you need to know at the start of execution, no matter how thorough a planning process has been.  The goal is to gather enough clarity to get started, and to set up a transparent process for learning and sharing results along the way.  Precision is not sought-after while making estimates (guessing), but is to be desired and expected as a team works together.

When you have committed a lot of time to be spent in a planning process, change becomes a threat to be controlled or eliminated.  In reality, change is an ever-present constant, which can be channeled into productivity if it is recognized with thoughtful response.

Bottom Line from The Agile Manifesto: Agile values responding to change over following a plan.  

Organizing Workflow in Agile Mode

Responding to change does not mean operating in a chaotic or unstructured way!  On the contrary, a definite structure to the workflow is necessary in order to measure what in fact gets accomplished.  In the Agile framework, workflow is organized into “sprints,” time periods which have specific beginning and end-dates.  Based on all the priorities identified in the plan (called a backlog, to be explained in more detail in the next article) the team commits to what it can accomplish within a given timebox.  That commitment – to accomplish X by Y date – constitutes the sprint and is to be considered a team not an individual effort.

Defining “X,” or what the team will accomplish together within a very tight timeframe requires that all team members maintain a customer focus throughout the sprint.  In other words, everyone involved with a project must understand how the work produced is going to be used in the real world and why it is in demand.  The meaning of the work is embedded into Agile workflow practices and constantly accessible to the team because of the Agile focus on organizing tasks by creating short narratives based on customer wants and needs.

These short narratives that define the workflow in Agile mode are known as “user stories.”  To take an example highly relevant to the nonprofit arts world, instead of a plan that reads “consultant will research funding prospects for Executive Director to distribute to the Board,” the Agile translation would be “As a Board Member, I want to review a current list of funding prospects so that I can fulfill my fiduciary responsibilities.”  The consultant and Executive Director work together to make that story come true, but they are not the focus of the work.  The “customer” is (i.e. in the arts world, stakeholder).

Bottom line:  Commitment to completing work within a given timeframe fuels high productivity.

Managing Teams in Agile Mode

Let’s look at project management as a discipline.  Its place in the business world has become well-defined; most projects require an administrator whose job it is to run around with a club making sure everyone involved is on time and on budget.  The project manager holds others accountable, because ultimately they are accountable themselves.

In the arts world, creative projects have managers (choreographers, certainly, fulfill this role) but on the administrative side things are not so clear.  Many administrative “projects” do not have managers per se other than the organizational directors.  Without a defined project manager, collaborations tend to get bogged down and become more trouble, sometimes, than they are worth.  Then around final report time, grantmakers are asked to go into the back room and sprinkle pixie dust all over everything to make it sound good.  Grantmakers get tired of reading “spin,” and everyone wonders what the real outcomes are for the money invested.

Projects are led by a  Scrum Master in the Agile framework.  The Scrum Master functions as a team coach.  He/she is responsible for facilitating meetings, listening to reports from the team, identifying obstacles to getting the work completed and removing them, and helping the team understand any changes in specifications as the customer/stakeholder’s wishes become increasingly better understood.

Another important function of the Scrum Master is to lead a retrospective at the conclusion of a sprint.  This will be a familiar concept to performing arts administrators, similar to a “post-mortem” after a production.  The retrospective is focused on three simple questions:

•    What went well?
•    What did not go so well?
•    How can we improve?

Answering these questions makes the next planning process rather a no-brainer, as the next set of work becomes mapped out and refined automatically.  Agile teams are self-organized in that each team member has an intrinsic commitment to accomplishing the goals of the sprint, and the Scrum Master functions as a coach rather than a dictator, taskmaster, or guy/gal with a club.

Bottom line: Agile management is focused on teams rather than individuals, but individuals and interactions matter more than processes and tools for getting work done.

Why is Agile relevant to the arts?

This appears to be a watershed moment: alongside the eternal cry that arts organizations should become ever more businesslike in a traditional, fiscally buttoned-up sense, businesses are now striving to be more and more creative, to think and operate more like artists.  The cultural membrane is stretched very thin right now between non-profit and for-profit forms of innovation, minimizing their differences.  As a result, producers and practitioners of all kinds can meet and profit from the exchange of ideas on a more level intellectual playing field than ever before, where no one sector is presumed to have all the correct answers and mutually meaningful collaborative learning can take place.

Focus here on the Agile framework represents one set of specifics in that vein.  The arts community itself must determine its ultimate relevance and usefulness.

Further information on the Agile framework and Scrum training is available at and

Please provide feedback on this article and related topics here or to  MANY THANKS.

%d bloggers like this: