July 22, 2014

Agile Coaching Blog

Agile Coaching Blog

This agile coaching blog has news & articles from BigVisible coaches and trainers. Find agile topics like Scrum and Kanban. Read about collaboration, communication, & enterprise agile. See hints for better daily meetings, retrospectives, and Scrum reviews. Learn about leading edge tools for lean startup and customer development. Discover information geared toward agile teams as well as leaders & executives.

We hope the information you find here will help your organization become more agile, adaptive, and innovative. Our goal is to help you delight your customers & succeed beautifully.

Postcard From the Field: “It’s beautiful. Wish You Were Here to Share Our Agile Success!”

Over the course of the last couple of months, I’ve been working with a client who is interested in changing their approach on how to handle what they term as “Big Rocks” in IT for planning, execution, and delivery.  We had our first demo and retrospective yesterday, and I felt a tear of joy in my eye.  So, I thought I’d share a little progress report from the field with you on some agile success.

We started with a business requirements document that took about 2 people years to develop.  Some of the items in this long document were items that haunted the organization for up to 4 years.  The normal next steps would be to take the requirements and submit them to the various silos of development for specifications, come up with project plans, manage the dependencies between the development silos, engage QA, and hopefully integrate everything together at the end and release the new and improved system.

My coaching and mentoring strategy was centered around the normal set of Agile and Lean values, principles, and practices that I employ to get organizations thinking in an Agile mindset.  I did add a new visualization to the mix, the “Agile Fluency” concepts that started with James Shore and Diana Larsen, which are being popularized by Martin Fowler.

Agile Fluency

We would start with the business leaders and decision makers on making a shift into business value focus at the organizational level for teams to be newly formed and sustained, with each team able to deliver independently on the software side of the value proposition considered.

Strategic Planning 

From the start, I made it clear that whatever new process we came up with, I wouldn’t just try to make for better planning of dependencies between the software layers and better tracking of actuals versus estimates.  To start, I wanted the organization to take a fresh look at what made sense to do from an economic perspective, and then use Lean principles of waste elimination to guide us on how to execute the plan.  Core to all thinking was the concept of a feedback loop, so we could constantly exploit variability as the landscape changed.

The results were both surprising and expected.  After looking at appropriate lightweight monetization of benefits and cost, the first and most beneficial epic emerged – which was to be expected.  However, what was surprising was how the business started to see that a point of diminishing returns would be reached only 6 months or so into the backlog created from the initial business requirements document that would easily be expected to take at least 18 months to complete.  This started raising eyebrows and opened people’s eyes about how to better spend those development dollars for other items on the organization’s portfolio of work to consider.  Rolling budgetary planning would occur monthly (which I think is a bit too rapid, but we needed to try and learn from it).  The organization decided to stop forming teams around projects, limit their WIP for projects under development, and bring the work to the teams as part of their Scrum product backlogs.  There were some vocal skeptics about how this could never work, but the client’s senior leadership team gave the go-ahead for a limited trial of the new way of approaching work.  For me, I couldn’t have been happier! 

Rolling Agile Planning

Tactical Execution

As we started up the first team to execute on the newly value focussed single stack ranked backlog of work, we faced a really tough decision.  The organization was used to silo development with project-planned dependencies resolving the (infrequent) points of integration with a UAT blessing at the end saying that the right stuff was built, followed by a QA stamp of approval that everything in the applications all still work.  The application architecture was rather complicated, with web, middleware, and backend layers of components.  The deployment process is manual, hard to coordinate, and fraught with peril.

My suggestion for Scrum team formation was to bring all the development layers together with the Product Owner into one project room and begin to develop the skills to consistently deliver on the value.  Additionally, I really wanted some of the Agile Engineering practices of Continuous Integration, Automated Regression Testing for both white and black box testing, and Automated Deployments to be started and gain some traction. I felt that without reducing the entire concept to cash cycle time, these new organizational cultural shifts would be tossed aside quickly as hard and expensive, and a reversion to the status quo would quickly occur once I left.  We got support from all the development silos with the exception of QA, who pledged to add a person to the team, but would not commit to enabling them to develop automated tests as we developed the code.

Our initial iteration planning went as well as could be expected for a team that was unaccustomed to working with one another in such a close and collaborative fashion.  Our Definition of Done for stories included using Ant build scripts that invoke JUnit, SoapUI, and Selenium webdriver/PageObject tests run on a Continuous Integration server (which was to be built in this first iteration).  It was a pretty tall technical order with huge uncertainties for a team that needed to get comfortable with a new way of how *they* approached work. 

I was honored to see this team get its work done.  Was it perfect?   Nope.  We had to do some backlog grooming a few days into the iteration, because we hadn’t had a chance to get completely through the backlog, and wanted some idea about what the general shape of the release would look like.  To our horror, when we started digging into the workflows and UIs that support them, we saw that a story that we had completely worked through make it impossible to implement something that we now were trying to wrap our arms around.  Right after we discovered this, the Product Owner had to go to the full Delivery Team and say, “Gang, I know that this is what I said we needed during our iteration planning.  But don’t do that.  I just figured out that I need something else!”  Conversations were had, and the team felt comfortable once again.  At the end of the iteration, during the demo, the Product Owner recounted the story, and then explained to everyone, “if we had done this in our previous process, we could have had to wait 3 months to even see that we had a problem!”


Image Source

The demo was also super cool when the developer that put together the CI server wanted to show what the tool looked like and what it did.  Just that day, the developer was asked about a small change that needed to be researched from an architectural perspective for the next iteration.  Going out on a limb, the developer made a code change in that direction during his demo, and committed his work.  The CI server kicked in, and allowed him to show the product owner what that new feature might look like.  In real time! Before, that level of system integration would have taken days to deploy, just to show what something would look like. In the past, decisions would be made based on documentation, but that’s not as valuable as seeing the actual new feature running!

Anyway, it was one of those all too rare victory moments for teams at this client.  Senior leadership team members were thanking the team and saying how they were amazed on the amount of progress that could be demonstrated in just two weeks.  We have a long journey ahead, but we’ve gotten started on the right foot.

Anyhow, I was so impressed with this team’s progress that I decided to send this card and share their success with you. It’s beautiful. Wish you were here!


Image Source


Want 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.



The Release Plan: The Who, What, When, Why and How

The release plan is the team’s current understanding of what features are going into the next release of software, how many effective developers are deployed on it, and the current status of the development effort. But how do you go about planning that release, especially if you don’t know your velocity?

In this video I’ll cover how a team plans a release based on a groomed backlog and come up with an initial velocity of the first sprint. How it works and the results of each sprint will update how the plan is published and moved forward in subsequent sprints. I’ll walk you through the steps on how to plan an entire release.

Want 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.



Why Continuous Delivery is the Goal

When I ask Delivery Teams and their Product Owners what the goal for their release is, they tend to tell me things like “we need to get stories x, y, and z into production.”  Or, “we need to get the new features for our call center live on date abc.”  And so on.  Notice the plurals on “stories” and “features”? That’s code for “we have a big old batch of stuff that needs to go out on time and on schedule.”  Anytime I see that sort of “big batch thinking” going on, the hair on the back of my head starts standing up.

If I then ask what the goal of their current iteration is, they tell me similar things, such as “we want to make our commitment on stories q, r, and s.”  What’s in the commitment?  Stuff like work done to the team’s definition of done, acceptance by the product owner of the work done, etc.  When I ask “what about creating potentially shippable code at the end of the iteration?”, I’ll get responses like “Well, sure. Right after QA has a 2-4 week window to test it.”  That’s right about the time that I cry a little.  At least on the inside.

The goal of Agile/Scrum development is about delivering value to the organization – and quickly – would be nice. Delivering on a schedule that the business can control by understanding how their demand will translate into a schedule by looking at things like velocity and variability, and having the ability to rapidly respond to change is even better.  But the goal is not the code per se.  The code that we iteratively develop and deliver is merely the way that we deliver value to the business.  The cost of those deployments is a drag on the lift that the value to the business provides.  In terms of aerodynamics, a headwind equates to the challenges and opportunities our businesses face.  Thrust is provided by the value of the software we produce to travel through those winds faster and higher than our competitors.  However, if we introduce drag, in an airplane it’s by raising the nose to climb (and angle of attack) and in software it’s by releasing the code to production with significant costs (because of the need to regression test, etc.), we cut down on our ability to move forward.  In an airplane, too much drag results in stall.  In a business, too much drag results in a failed business.

Inclination Effects of Drag_img

We can do deployments the way we’ve done them – since fire was a disruptive technology. We can painstakingly plan deployments, trying to make sure that dependencies will come together and everything is updated in a big batch after careful testing and validation by QA that no regressions have occurred.  Or we can start to move into the 21st century of development.  I want to argue that continuous delivery of code is the real goal.  And I want to argue that even if the cost seems higher (because we still are thinking in big batch terms), when we begin to use a holistic systems thinking mindset, continuous deployment makes real sense.

I’ve come to think of the cost of code deployment (that inter-team release planning and QA effort) in the same way that we used to think of ordering goods and materials from suppliers.  Except when we ordered goods and materials, we spoke in terms of shipping and handling costs.  And then Amazon Prime happened. Overnight, everything changed.

For anyone not familiar with the specifics, Amazon Prime is a premium membership offering from Amazon.  It started in 2005 and cost $79 a year (a prime number) until March 2014, when it’s rate was changed to $99 (which is about what the $79 in 2005 dollars translates into in 2014 dollars).  Amazon Prime includes stuff like free streaming video and free Kindle books (for some media titles), but I’m not interested in that stuff.  The real treat of Prime is the free 2nd day shipping, with deeply discounted next day delivery.  It has been estimated that Amazon loses about $11 per customer by offering Prime (see Amazon Prime Loses $11 Annually Per Member … And It’s a Huge Success). Which reminds me of the old joke that we told ourselves in the dotCom days of “we lose money on each customer, but we’ll make it up in the volume.”  But Amazon doesn’t seem to be going out of business anytime soon. Quite the contrary.  How come?

Amazon is a company that employs holistic systems thinking.  Their basic thought is that the more customers they can attract and the less friction per transaction, the more flow they will get through the system.  And from a highly non-scientific study of me and my wife’s interactions under Prime, it works. Why is that?

When you use Prime, you don’t think about batching.  I need something.  I check Amazon.  The price is usually very competitive (to the point where, quite honestly, I don’t even check many times).  I feel safe in the promise that Amazon offers which is basically “We will deliver the goods we sell on-time and without defects or you can send them back to us at no charge.”  They have validated that promise to me many times, and it makes me feel safe ordering from them.  With Prime, I don’t have to worry about batching things together.  View, click, and wait 48 hours.  Done and done.  Instead of larger batches of stuff (where I have to ask myself things like “do I have budget for all that stuff?” and “where will I put all those things?”), I order just what I need, when I need it.  With Amazon, the experience is quick, easy, and safe.  When my wife needs shoes, she orders them from Amazon just to try them on and see how they feel.  The ones she doesn’t like she sends back.  Easily and quickly.  In other words, she gets to experiment on value for her, for very little cost.

Hmmm.  There seems to be an analogy between that last paragraph and what Product Owners want.  What if they could see something that they want (a software feature, not shoes), and feel confident that they could get it quickly, hassle free, and could always trade it out for something that they really want, once they see the fit between what they thought they wanted and their situation?  Yup.  They’d stop all the lean waste in planning for big batch releases in a heartbeat!  Remember, from a Lean perspective, release planning is a cost without a customer benefit.  We want to kill as many wastes as we can find!

By the way, Amazon eats its own dog food when it comes to practicing what they preach.  (see Velocity Culture – The Unmet Challenge in Ops).  Amazon has reported releasing every 11.6 seconds.  And they report hitting a high of 1079 deployments in an hour.  On a maximum of 30,000 hosts receiving a deployment. In addition to the local optimizations for reductions in outages caused by deployments, think of how delighted Amazon customers, like me and my wife, are.  But there’s another community of delighted people: the Product Owners at Amazon.  They can turn an idea into code, deploy it rapidly, see the effects of what that code change affected with validated learning of non-vanity metrics (think A/B testing), and pivot into the real code that they need.  Quickly.  And return the stuff that doesn’t fit or look good (in shoe terms).

How do we get closer to where Amazon is?  The first thing we need to do is recognize that Continuous Integration is not the end game.  We still need CI servers to test that the code we produce continues to have the quality that we can count on.  We get that with automated testing, including automated regression testing, but that’s just the first step.

We have to stop committing so much waste in branching our source, especially “feature branching.” Ultimately, anytime we conflict merge from the repository, we still need a smart human resolving conflicts between branches.  That’s slow, expensive, and error prone.  We’re better off using good loosely coupled architectures to “feature branch” in, so we can build resilient interfaces to use feature abstractions that the software presents.  That’s why Martin Fowler quotes Dan Bodart as saying that “Feature Branching is a poor man’s modular architecture” and leading people into design patterns such as FeatureToggles and BranchByAbstraction in his article on FeatureBranching.

And we have to extend our thoughts on what Continuous Delivery means in a CI machine.  Deployments need testing.  To make sure that the deployment occurs as expected (“Can we provision virtual machine images for the new system?”, “When we deploy those images, did the load balancer die?”, “Did the app server quiesce to permit the changes?  Did the database migration occur?  Can we verify with a smoke test that all went as expected?”)  We have to automate the operations in the deployment so they can be made at machine speed and operate without human interaction.  We only want humans employed to verify that those automated operations went as planned.  When we can do that, we have given the Product Owner options as to smaller and smaller batches of features, because the cost of deployments can be made tiny.

Will there be a cost to all of that automation?  Yup.  But you know what?  Looking holistically at the organization, that small extra cost of lowering the costs of deployments and making releases become quick and easy everyday events will soon become your organization’s Amazon Prime.  And imagine the glee that your Product Owner will have when he has the ability to order more shoes to find just the right ones – with free 2nd day shipping!

Want 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.



Effective Lean Portfolio Management – Stopping The Thrash To Make Some Cash

I was lucky enough to be involved with a mid-sized client recently who happened to be in the medical insurance analytics industry.  Lucky is maybe a weird way to say it.  The engagement was one of the hardest I’ve been involved with in recent memory.  But as I look back, the outcome was so satisfying that the success overshadows the pain we endured.

Things were fairly desperate when I got to this client.  I had a briefing from the CTO of the parent company on what was happening.  I was asked to help the PMO figure out how to do a better job with portfolio management and help Development staff get stuff done.  I made the following observations:
  • Development was extremely busy and no one was very happy.
  • The product that Development produced had a reputation for poor quality, and that didn’t make the business team big believers in the ability of Development to deliver on time, on feature, or on budget.
  • There was never time to do the right things because there were constant emergencies that development had to quickly react to in order to avoid disaster.
  • The way that the company approached work was to get funding approved through the PMO (a lengthy process) and then form a team of developers that were already working on other items.  That is, new work that got approved (such as emergency work) simply given to already saturated resources.
  • The PMO worked against project proposals, and the primary factor to getting a project approved was to verify that funding could be secured.
  • Projects were tiny, down to the size of mere sub-features.  Just about ll decisions were preplanned in terms of features, approach, and people.  The planning of project-to-project dependencies was enormous, and when things changed, which they did frequently, things were replanted ad nauseum.  Progress, when it occurred at all, was in tiny increments, and took a really long time.
  • iStock_000031710336Medium

    So, this wasn’t a simple case of “Gee.  We have 7 people in development, and they say that they’d like to try Scrum to do their work.  Can you train us up and get them started?”  For BigVisible to be successful with our client we had to:
    • Only claim success if the client was successful.  Did that mean that all six of the problems observed were completely gone, the sky was bright blue filled with rainbows, and that unicorns dotted the landscape?  No, but we had to at least move the needles in the right direction on the problems.
    • That implied that solutions straight from the “Agile Playbook”, like a great plan to roll out Scrum and train everyone up wouldn’t fly.  BigVisible is known for creative non-obvious solutions, and however hard that would be, we’d have to be up for the task.
    • We also had to not be afraid of “the storm” with the client.  There was still political fallout at the company. Reduced product deliverables were resulting in reduced revenues which was resulting in reductions in the workforce.  This all made the atmosphere at the client quite toxic at times.
    In thinking this through, I decided that the focus of this portion of the engagement was not about the delivery and execution side of the equation at this level. I didn’t want to focus on team level metrics when looking at these strategic issues. I knew that eventually, we needed better Agile Engineering practices, such as automated regression testing, to get better quality.  But it was my feeling that pivoting the client to focus on value delivered (rather than cost of production) and looking at a smaller number of projects overall would be helpful.  From a lean perspective, way too many decisions were made too early on, and ended up having to be analyzed again and re-decided.  Those decisions were made in a document-centric fashion, and were expensive both in terms of time to create as well as time to distribute and educate.  The decisions were also made not just what needed to be done, but how to do it.  Those “how will we do it” decisions were made by non-delivery people who, although good-intentioned, were not necessarily in line with either the reality of how the systems actually worked.
    In a nutshell, I wanted the organization to:


    • Plan less projects and plan less deeply.  The projects should allow negotiation from a “backlog of work to be done” perspective.  The projects should not have all the design decisions and estimates pre-made, especially by those who do not actually code the work.
    • Include value in the decisions of which projects to go forward with.  Stop planning to only control cost, but start a pivot to plan for the best value, using cost as just one factor.
    • Limit the number of things that the organization works on at once, so that the organization could become effective.
    • Appropriately manage the portfolio of work “in process” and “to be done”.  Make economically rational decisions on the portfolio.  Plan based on a roadmap of value and review the progress periodically. And, much like the way a stock portfolio should be managed, don’t fall into the trap of the “sunk cost fallacy.”  Instead, I wanted more of a “bygones principle” to be used when making decisions.

    DCF 1.0
    At BigVisible, we feel that a transformation performed without goals and results is just an exercise for a customer to try out some potentially cool stuff and see if they like it.  We don’t believe that we are in the business of having a hip storefront that advertises how cool you’ll look wearing some new process.  We don’t believe that the way you measure the success of an engagement is to see how much behavior the client is doing that seems more “Agile”.  We believe that to be Agile, a client has to have better outcomes than when they started.  So, we set the following goals for measuring our success:

    • Do releases occur without heroics?  Or are they followed by countless emergency releases?
    • Do releases occur with the MVPs (minimum viable products) as part of the release?  Or do they consistently disappoint due to quality of features so poor as to render the release a toxic wasteland?
    • Does the finger pointing and tension between Product and Delivery subside and actually have them form a real team?  Or does constant acrimony between the two sides continue?


    The transformation didn’t always go smoothly.  We instituted our own Lean BMC (Business Model Canvas) and added items to help visualize cash flow over the effective life of the product, monetizing costs, benefits, and risks.  It was hard on the organization to think about work differently – we were asking them to not make tiny decisions about what, how, and who for each small feature or defect.  We were asking them to limit their work and attempt to create a single rank ordered list of potential work. We were trying not to “optimize” by matrixing the organization’s staff in a fashion that would destroy their effectiveness through constant meetings and task switching.

    Two people were thrilled with one aspect of the transition – the CEO and the CFO.  The use of NPV (Net Present Value) calculations to forecast cash flow and understand the capitalization implications on their business resonated with each of them.  While they really wanted precision in accounting, they understood that better accuracy due to not just looking at the costs, but also considering the benefits side at the same time gave them a powerful tool to understand what products should survive in the rolling management of the portfolio we put in place.

    Interestingly, when we started with planning the portfolio by single stack ranking the product proposals, we decided to get right at it.  We brought the heads of Product and Delivery together; sat them in the same room.  And they took the time to plan the business as part of a real leadership team.  There were very tense and tiring days, especially the first time through the process.  However, they both agreed at the end of the strategy sessions that they found deep appreciation for the issues and common ground to build upon.
    Now don’t get me wrong.  Things were not perfect.  There was a “pet project” that we knew would lose a relatively small amount of money.  And somehow, we could never cross that line and drive a stake through its heart, kill it, and keep it killed.  But at least people were able to articulate that, instead of using politically aspirational excuses for keeping the project going.
    So what did we learn, and how did the client’s work change?


    • We learned to focus on product value, and think in terms of longer timeline horizons.  We had to put hyperbole on a holiday, and actually make economic sense quarter by rolling quarter.
    • We learned to limit our work in progress (WIP), match demand to supply, and start thinking in terms of bringing work to established product delivery teams, and not just forming “teams” around scattered projects. Less thrashing around allowed us to focus and actually deliver quality product.  Teams were redirected into new product work, only on a quarterly schedule that allowed them time to focus and finish that which was started.
    • We learned to think about appropriate measures and metrics in terms of strategic planning.  We didn’t optimize the individual projects.  We optimized the organization.
    Oh, one more thing.  That client recently contacted me to ask about how to better integrate their process with corporate FASB and GAAP capitalization policies.  I was also informed that they are improving on their BMC on their own.  Nothing could make me happier.  Hopefully, they will continue to improve and set the bar even higher for Lean Portfolio Management!

Want 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.



The Capacity for Change – An Agile Case Study

Improving quality and speed-to-market, two of the most common challenges an organization can face. Now get 10 teams to meet that challenge and scale it further in order to better visualize the work flow across the business. Maybe even set up a few “enablement teams” to make sure that success is sustained. Here’s an agile case study on an organization I’d like to introduce you to. They’re the organization that did it…successfully!

Just the Facts
The Challenge: Train and launch agile teams for the product group of a broadband Internet pioneer with 400+ employees.

The Client’s Goals: Better follow-through on execution, faster speed to market, higher quality

The BigVisible Approach: Assess the current situation, design a plan, start sprinting. Adjust the plan, scale, and offer suggestions to sustain results.

What We Delivered: Results that met client goals, plus an organization-wide understanding of capacity versus demand.

Over a seven-month period, our agile coach worked with a broadband Internet provider to launch 10 agile teams with the goal of improving quality and speed to market. Using the SAFe framework, our agile coach helped the leadership team better visualize the flow of work across the organization. This big picture view enabled them to reduce log jams by pulling from a prioritized product portfolio. The client also implemented two agile enablement teams, who are working to sustain success by extending agility beyond the software teams.




All About Agile: Giora Morein’s Interview with Money For Lunch

Earlier this month, I was interviewed by internet radio show, Money for Lunch. The program introduces leaders, authors and innovators to a business-minded audience focused on business and financial news. I spoke with Bert Martinez regarding the topic of agile. We went over some of the basics, such as:

  • What is agile and Scrum?
  • What are the common pitfalls of agile or anti-patterns an organization might see?
  • How does BigVisible avoid the pushback and get organizations to successfully adopt agile?

I speak to the topic of agile as a fundamental shift in how large organizations view the delivery of products and projects – going from big batch, long-phased delivery cycles to something iterative and incremental – quickly bringing products to market.

It’s easy for organizations to become bogged down in their own processes and systems. But more and more, organizations are widely adopting and scaling agile to be more responsive, to increase quality and achieve more successful outcomes because the market is demanding it. Buyers are more knowledgeable and know what they’re looking for and they demand better product in shorter timeframes. If organizations can’t deliver, they won’t be able to remain competitive.

You can listen to the full interview here.

Want 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.



Agile Coaching: An Inside Look – A BigVisible Webinar


Many companies seek to be agile in order to; better adapt to changing requirements, market place, and customers; to build not just any product but the “right” one; to get their products, services, and enhancements to market more quickly; and do so with high quality levels. Enterprise agility seeks the same outcomes but is done at a much larger scale, and the larger the enterprise the more complex and complicated the needs and challenges can be.

It’s been demonstrated time and time again that working with an agile coach can dramatically improve success rates, accelerate adoption, and when done well catalyze lasting and sustainable change. But what does that really mean and how can a coach help? Agile coaching has become such a sought after service and it’s momentum stirred up so much dust that it’s left company leaders cloudy about when to engage an agile coach, what to expect when working with them, and how their services can actually enable the results their organization seeks.

In this webinar Jeff Steinberg, one of BigVisible’s Sr. Agile Coaches will let people in on the mystery of:

  • Why agile coaching is so crucial to successful agile adoption and lasting transformation
  • What agile coaches do and when to engage one
  • How agile coaches partner with you to:
  •    – Identify and overcome weak spots
       – Develop and implement holistic strategies for sustained success
       – Enable high-performing teams, programs, and large organizations
       – Become the internal agile coach at your organization



Give Credit to Collaboration and Commitment – An Agile Case Study

Part of scaling agile across the enterprise is to successfully enable change management. To help manage that change, leadership needs to understand and value a culture of continuous improvement and encourage its teams to provide input into the decision-making. This agile case study demonstrates how a financial services company did just that…

Just The Facts:
The Challenge: Train and launch agile teams for the credit group of a financial services company with nearly 250,000 employees worldwide.

The Client’s Goals: Launch pilot program and scale so that teams can delivery more quickly and with greater predictability. Increase understanding of leadership/management role on an agile project.

The BigVisible Approach: Assess the current situation, plan customized training & coaching, start sprinting with a pilot team. Adjust the plan, scale, and offer suggestions to sustain results.

What We Delivered: The successful launch of 10 agile teams, some co-located and some distributed. A culture of continuous improvement and team input into decision-making.

Not too long ago, a financial services company called on our agile coaches to work with both leadership and development teams as they transitioned to an agile process. Through a combination of training and coaching, BigVisible coaches helped a 120-person group successfully launch 10 agile teams and institute company-wide practices for sustained success with Scrum. By the time our coaches left, features that used to take more than a year to build and release were complete and ready for production every month. Teams that used to work in silos, unaware of how their work impacted others, became a cohesive group, working together toward a common vision and achieving previously unimaginable results.




An Investment in Innovation – An Agile Case Study

Not every organization that “does” agile does it well. Sometimes the principles work well for awhile, but the teams aren’t able to innovate or make the successful results sustainable. Here’s an agile case study that addresses an organization that values agile principles and practices, but needed a little help to sustain their success and innovate.

Just the Facts:
The Challenge: Help existing agile teams manage rising levels of burnout and technical debt.

The Client’s Goals: Establish a sustainable pace, faster speed to market, higher quality.

The BigVisible Approach: Assess the current state of agile in the organization. Design a path forward and start implementing that plan. Learn, adjust, and scale accordingly. Give the client tools to sustain success.

What We Delivered: Adding technical practices & increasing the understanding of agile principles led to dedicated time for innovation, which in turn created a culture of quality, ingenuity, and faster, more reliable, deliveries that better addressed customer needs.

A financial services company was bogged down by the relentless pressure to deliver and asked us to help their teams manage rising levels of burnout and technical debt, with the ultimate goal of establishing a sustainable pace, faster speed to market, and higher quality. Our agile coaches helped the teams break away from destructive patterns and find new ways of working. Through training and coaching, BigVisible coaches helped to reset the agile effort and create a renewed focus on small, cross-functional teams, a steady iteration cadence, and the importance of building quality into delivery. The result was a fast-moving program whose teams can deliver consistently, at a healthy and sustainable pace, while carving out time for innovation and improvement.




Agile Changed Their Lives…From The Trenches of a CSM Training Class

As a long-time agile coach and trainer, I have had the privilege of teaching many types of agile courses, but more recently, I’ve been focusing on Scrum certification training for BigVisible. I teach certification classes available to the public, as well as private engagements with our customer organizations. Not too long ago, a request came in from a PMI Chapter, looking for a three-day class that teaches the fundamentals of Scrum to become a Certified ScrumMaster and prepares project leaders for the PMI-ACP exam.

Along with the usual challenges of a three-day class (longer days, more materials, additional preparation) another potential challenge began to reveal itself. This class was on the larger side (30 attendees) and made up of an audience of seasoned project management professionals well-versed in traditional/waterfall project management and not very familiar with agile methodologies. What I did know was that there was a thirst for more Scrum knowledge in general, not just preparing for the PMI-ACP exam. But that still didn’t calm my apprehension. Past experience had shown me that project managers tended to be a tough crowd. I mean, after all, these folks were seasoned PMs who have been doing their job for many years and doing it successfully. Now, they’re being asked to take a different approach and manage projects in a new manner.

One of the many things we do well at BigVisible as part of our class experience is not to sell people on agile, but to get participants to learn from one another, share their experiences and have valuable discussions with one another. We use hands-on exercises and interactive simulations throughout class to teach agile principles. This helps people feel more at ease with the concepts and feel confident in a safe environment that they can apply their knowledge and feel prepared to take on a Scrum project. That’s not to say they’ve becomes experts, but they’re more prepared with the tools and knowledge to take on projects in an agile fashion.

As our class kicked off and we moved through the exercises, there was an arsenal of questions, including “how does this work in the real world?” or “how is this different from what I’ve done the last 15 years?” Even with all the materials I had and the planned simulations, I still needed to make it real for them. I shared my past work experiences at previous organizations. I was able to articulate the benefits of agility, such as: reducing risk, quicker delivery of product, higher quality and more satisfied customers. Collectively, the group shared lots of their own stories, tapping into their own experiences of success and failures of past projects. The dialogue was rolling.

As this sharing continued over the three-day period, you could clearly see this group morph from being skeptics to advocates. They began to shift their thinking from “this will never work” to “how do we make this work in our own environments”. They were truly interested and engaged and the deep discussions continued. Then another wonderful thing happened. This group was so intent on learning, applying techniques to exercises and figuring out how to make agile work for their organizations – they really began to bond. It was such a strong bond for such a large group – but they became a community, a support system.

They wanted to have access to this support system and continue their discussions outside of the class. A good handful of people from the class approached me about creating an online community for them. I told them about our Training Alumni LinkedIn group – but they wanted one specifically for them. One of the participants created a LinkedIn group just for them and EVERYONE opted in to participate. Surprisingly, it’s been a long-lasting, active and collaborative community. They still share successes, praise each other when someone gets certified, share experiences, and initiate discussions.

As we wrapped up the class, what happened next will be something I’ll never forget. In addition to providing complimentary feedback about the course through our feedback forms, a several people individually took time to approach me. For each of them, this class became a game-changer for them; that it actually changed their lives.

Taken aback, I asked them what prompted their comments. As experienced PMs, they were starting to feel that their skills and approach were not as valid or valued as much anymore. To them, their new knowledge would open doors to new opportunities or new ways of succeeding in the current roles. The class put them in a mindset that felt like a new beginning for them, a breath of fresh air. The world was changing around them and they now felt like they could adapt and change with it.

What I thought was going to be a challenging three days turned into a very rewarding and fulfilling experience. This was a group that clearly got out of what they put into the experience.

For this group it was about the people, the dialogue and interactions. What’s been the agile game changer for you?

Want 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.