For years I’ve been lecturing and writing about the process of adopting Agile.  Specifically, I’ve been promoting a model that Stephen Forte and I call the “Agile Buffet” where change, in this case the usage of Agile practices on a team, is pulled into the team incrementally based on real observable needs.  I’m certainly not the first to suggest such models as organizational change is a heavily researched and written about topic.  I entitled this post “starting organizational change” for a reason.  First, I feel that I find myself glossing over some of the real challenges that teams have when facing change.  Second, the adoption of change, even when it comes to Agile adoption, is rooted in basic organizational change techniques.

Make no mistake – organizational change is tough.  There are many forms of change within an organization; from reorganization of a company due to an acquisition, management change or even the adoption of different practices to help with efficiencies or innovation.  Many organizations fear change – they feel that change is disruptive causing a loss in productivity.  Some managers mistakenly believe that if they can just keep people focused on their day to day job organizational changes are less impactful and disruptive.  Unfortunately, this leads to a downward spiral where change can actually become impossible or very painful (a self-fulfilling prophesy). The truth of the matter is that a great organization is constantly changing.  In fact, one of the characteristics of amazing organizations is how well people within that organization embrace and usher in change.

There is only one constant in the universe – and that is change.  You and your organization/team/division (whatever scope you want to work in) only need to be good at ONE thing – and that’s managing change.  The rest is trivial.

Shocking Reality

I first started to get passionate about organizational change when I began to adopt Agile practices on my own teams.  I was shocked at how much resistance there was.  These practices made total sense to me – it was a no-brainer for me to jump right in and adopt EVERYTHING Agile – yet for others there was much skepticism and even resistance (and in some cases out right sabotage).   It was then that I realized that I couldn’t just push practices on to people – I had to start with the reason those practices made sense.  My team needed to have the same common perspective as I had before introducing these changes.

Another reason I started to become passionate about the method behind agile adoption was that I got tired and angry listening to other agile zealots preaching things like “you can’t be Agile if you don’t practice Test Driven Development” or “if you aren’t following 100% of every agile practice ever invented, you’re still not Agile”.  Deep down I knew that this was totally incorrect.  This eutopic perfection that was being preached just didn’t seem achievable for 99.9% of the organizations I’ve ever worked with as a consultant and trainer.  Being Agile simply wasn’t an on/off switch.

Recently, the process of Agile adoption has come to the forefront as Gartner has recently expressed that Agile is close to entering the “Trough of Disallusionment” in its Hype Cycle.  This is an symptom of how difficult organizations have found the adoption of agile due to the nature of the organization and people within it.   This has been further reinforced by surveys from VersionOne that highlighted statistics such as “53% of companies thought that organizational culture was a barrior to the adoption of Agile practice and that 41% of companies believed that there was simply a general resistence to change.

I’m now certain that the process by which teams adopt Agile is more important than the Agile practices we want them to follow.

Inception

I compare organizational change to eating.  You can’t force food down someone’s throat.. they will just spit it back up.. and you don’t want them to get violently sick all over you!!!!.  That’s bad.  If you wanted someone to eat, get them hungry and then put food in front of them (healthy food of course).  This is where the term Agile Buffet came from.  The goal is to have teams get hungry (deeply recognize that a problem exists) and then to make sure that the buffet contains exactly what they need to be satisfied (Agile practices).  In this case, change is pulled versus pushed.

I affectionately call this process “Inception” after the movie. The entire plot of the movie centers around planting a thought into someone’s subconscious to get them moving down a course that would impact the future.  When you “start with the why” you are in fact planting the seed of change and causing hunger to grow.  Only when there is hunger (usually in the form of pain) change happens.

In reality, change in this way can only be stimulated by pain or gain.  That’s the only true reasons that anyone would change any of their behavior or practices.  They want to either eliminate pain or have something that they didn’t have before.  The common element between pain and gain is emotion.  Thus, managing change is much more about managing emotion than it is fixing a broken system.  Unlike computers or assembly lines – you can’t simply “fix” a human system without recognizing the human qualities that got it there – and the most important human quality is emotion.  Managing emotions is really what Inception is all about.

This may sound wishy washy – but it’s not.  I’ve experienced organizational change in many ways for the past 20 years – and it comes down to the same design pattern over and over again.   Humans are not robots or assembly lines – pure logic and metrics don’t always prevail as change motivators.

Setting Up for Change

I entitled this post “starting organizational change” because I actually wanted to focus on what is required to start inception (remember, inception is simply about making sure that people involved within the change deeply connect emotionally with the need).  What needs to be in place even before you start making changes to your organization is a shockingly simple pattern – yet is amazingly absent from most change management approaches.

The first thing you should realize is that organizational change doesn’t happen by accident.  Even when it does, it’s probably not the organizational change you want to see.  The first step to enable an environment to stimulate and control change is to breathe some life into it and make it a continuous project onto itself.   The method of process improvement must exist both outside and inside all other initiatives.  Just like every project, you need an environment first – hence this post.

Here is a definition of a simple environment that you need to have in place prior to any form of organizational change (provided you are going to be driving that change incrementally).  If you have ever worked with me, you’ll probably realize that this is the only pattern I ever follow and that the closer I follow it – the more success I have with change.

1.  Establish an initial “change team”:  Depending on the scope of your organizational change – this could be easy or a hard thing to do.  For example, for a project team wanting to adopt Agile practices, this team may be the entire team.  For an organization that wants to adopt new HR practices, this may initially start off with a subset of the HR and Management teams and then slowly expand to a broader audience once change begins to have momentum.  In almost all cases, the initial team will start small and then over time will expand to more people as the scope of the change increases and momentum builds.  In almost all cases, people are pulled into this team based on the scope of change that they can impact.
2.  Establish a cadence of structured dialog with your team:  Before any change happens, you must create an environment of engagement with your team.  This this form of engagement is about having a full and untethered dialog between team members.  This cadence should be the heartbeat of the team and should follow the same “pattern” every time.  Here is a pattern that you can use for this dialog cadence:
Timeboxed, high bandwidth discussion.  These discussions can happen weekly to start and then move to a longer cadence cycle if required, however, the span between these discussions should never exceed one month.  By high bandwidth I mean in-person if possible.   If not in-person, then video conference, voice, etc.  Try to avoid other electronic means such as email or shared chat.
Start the session with a round table.  For each person ask the following

• What they have been working on during the last period
• What they plan on delivering during the next period
• What things may have gotten in their way

The participants should then engage in a retrospective where the following is discussed:

• What is working well
• What is not working
• What are the biggest impediments
• What are the biggest opportunities
• What should be the focus for next round of improvement

The nature and structure of these meetings can and will often rapidly change over time.  For example, as teams mature they may want to change the meeting format to focus more on the flow of work rather than doing a round table.  They key is to establish a pattern of conversation with a focus on improvement.  Make a list of things the team wants to stop doing.  Make a list of the things the team feels they need to start doing.  In most organizations there is a lot of low hanging fruit that can be addressed without the need for more complex methodologies.

3.  Track progress and accountability:  This should be a no-brainer.  This cadence of discussion drives ideas that drive action.  This should be tracked.  It doesn’t even matter what tool you use – from Excel to more mature work tracking tools.  The bottom line is that you should be tracking everyone’s ideas as well as tracking the actions and accountabilities that follow.  This tracking list should help drive the further discussion of improvement and helps to ensure that the work required to make change is properly tracked.

4.  Measure… everything:  It is very important for teams to have a clear view of the metrics associated with the changes you want to impose.  The team should work together to help define the key indicators and the trend they want to see for each indicator.   For example, you may be introducing changes to sales practices and in this case would want to measure metrics like leads per month, conversions, sales volume, and sales cycle time.  Agile teams do this all the time measuring aspects such as velocity, bug rates, change rates – working together every month to slowly fine-tune practices to remove waste and become more efficient.  In fact, a lot of what comes out of early meetings are actions that revolve around establishing a base of measurement.  Many organizations simply aren’t measuring enough to use data to drive many decisions – they key from this step is that measurement will help drive decisions of organizational change and many of the early actions are going to focus on collecting and communicating measurement.

5.  Share… everything:  This is perhaps one of the most important aspects of the environment required for change.  The entire team should know as much as possible about at the scope of the intended organizational change.   Only by sharing all information with the wider group can everyone resonate in the same direction of change.  Of course, you will still have some things you just can’t share such as HR sensitive material or sensitive customer data – however, ensuring that everyone is on the same page with information helps to align the team as well as to solicit effective problem solving by the entire team.

When you implement this environment (which is a change in on itself) you create something I call a “change tuned environment” – where the entire organization is “tuned into” incremental change.

Some organizations I’ve worked with start more formally by doing an assessment about some future desired state, doing a gap analysis and then attempt to plot change.  For me, this has never been effective.  Start by having a simple and continuous dialog.  Teams should get into the habit of making smaller changes first and this is why I promote focusing on “low hanging fruit” – because any positive change is still positive and emotionally enforcing at the beginning of this process.  Sometimes tackling the biggest issues within the organization makes it easy for teams to feel a lack of progress when in reality it is much more important to start the change flywheel spinning.

Simple Pattern of Empowering Leadership

What’s really great about this design pattern is that just by following it you are working in a direction that will lead to you working yourself out of a job.  In fact, the goal of every manager and leader should be to work yourself out of a job.  Wow hey?  If you do this, you become an empowering leader who can scale decision making while at the same time create an environment that is ever evolving and learning.  In fact, this is exactly what the book “Good to Great” talks about.  Great companies have this culture and values something called a “Level 5 Leader”.  Simply stated, a Level 5 Leader facilitates an environment I just described by empowering all around them.

Patterns of Change

There are, of course, other methods that facilitate organizational change.  One of my favorite is the Kanban Method formalized by David Anderson.  In reality, there isn’t much new in any of these methods that hasn’t been adopted in the world of Lean Thinking (which stemmed from Lean Manufacturing that stemmed from the Toyota Product Method, which stemmed from Deming’s principles) or a derivative like the Theory of Constraints.  The crazy reality is that we don’t have to reinvent the wheel when it comes to how to do organizational change – it’s been perfected for the past 30 years.  We just have to embrace these practices and follow them ourselves.

With that said, if you distill these methods down you get the same design pattern – one that promotes incremental small changes that are continuous over time and managed discretely. It’s not rocket surgery but when it comes to managing a human system, emotions and perception is deeply impactful.

Of course, what almost every single one of these very successful models boils down to is what Taiichi Ohno called Kaizen in the Toyota Product Method.  It has become the foundation and core principle of my entire career and management style.  So, whether you are following Goldratt’s Five Focusing Steps to achieving the Theory of Constraints or the Kanban Method, or even more focused methods such as Scrum.org’s Agility Path, you will need to lay a simple foundation down first – and its this foundation that will get change to manifest and stick.  Establishing this environment is the first change – and is usually done from “the top down” – the goal is to ensure that all future change are manifested and delivered via facilitation instead of command and control.   Unfortunately, this first change might not be done in a collaborative way – but its nature will likely not be thought of as a negative change.

Before Change, Create the Environment

Whatever pattern of change you want to institutionalize, you must have the correct environment first.  Without an environment that allows change to self-realize, organizational change will not stick and will deteriorate into confrontation and dissidence.  In fact, this is my one simple litmus test for any organization or team.  If I sense any form of discontent or expressions of “us versus them” or claims of “stupid management” or an overly expressive emotional response – I know that the only thing that was missing was the environment of change.

Whether you are adopting Agile practices or want to simply improve your division or team in some other way, start with these 5 steps – and you will realize much greater success.

Some Material You Should Read

I’m not making this stuff up 😉  I just talk about it differently than others.  By all means, blow off my recommendations, but know – they aren’t truly mine to recommend.

Here are a few books that really had me thinking about change and what it means to teams – and specifically Agile teams.

• Good To Great: Why Some Companies Make the Leap…And Others Don’t
• Great By Choice: Uncertainty, Chaos, and Luck–Why Some Thrive Despite Them All
• Built To Last: Successful Habits of Visionary Companies
• Kanban
• The Goal: A Process of Ongoing Improvement
• Start with Why: How Great Leaders Inspire Everyone to Take Action
• Peopleware: Productive Projects and Teams
• Drive: The Surprising Truth About What Motivates Us
• The Logic of Life: The Rational Economics of an Irrational World
• Isn’t it Obvious
• Deming and Goldratt: The Theory of Constraints and the System of Profound Knowledge
• ReWork
• Sdlc 3.0: Beyond a Tacit Understanding of Agile: Towards the Next Generation of Software Engineering

Yes, I’ve read every single one… a few more than once (The Goal, PeopleWare, Build to Last, ReWork).  Just go and buy these books.  Don’t even think about it.  Consume them like they were a great class of wine.

Here are some important links for you as well:

http://en.wikipedia.org/wiki/W._Edwards_Deming

http://en.wikipedia.org/wiki/Kaizen

http://en.wikipedia.org/wiki/Taiichi_Ohno

http://www.djaa.com/blog

http://www.dbrmfg.co.nz/Bottom%20Line%20Accounting%20for%20Change%205%20Step.htm

http://www.scrum.org/Agility-Path

I’ve been on some amazing teams. I’ve been on not so great teams.  I’ve been a part of average teams that could be great with some tweaks.  When teams work well together, magic happens.

So, what’s the recipe of a great team?  Years and years ago I used to lecture on ways to destroy teams, inspired from my own experiences watching organizations destroy teams as well as some truly disruptive books such as Peopleware by Tom DeMarco and Timothy R. Lister.  So, if you inverse ways you can destroy a team, will that help you create a great team?  Possibly.

I came across another TED video this morning (over the holidays its amazing how much free time I have and I decided to fill it with some inspirational and enlightening videos on TED) by Tom Wujec entitled Build a tower, build a team.  Tom plays a game with teams called The Marshmallow Challenge.  Essentially, teams are asked to build the tallest freestanding structure they can in 18 minutes with a specific set of materials:  uncooked spaghetti, string, marshmallow, masking tape and paper lunch bags.  Oh, and the structure teams build must have the marshmallow at the very top.  He has conducted this challenge with all sorts of teams with very interesting results. Interestingly he’s found the worst performers were recent grads of business school.  Surprisingly, recent grads of kindergarten do quite well.

Why were the kindergarten grads outperforming the recent grads of business school?  First, the recent business grads didn’t do so well since they were all trying to take leadership of the team by attempting to exert their own single correct plan upon the rest of the team.  None of the kindergarten kids were trying to be the CEO of the team 😉 – they were focused on working with their team to find a solution.  In addition, the way the kids approached the problem was much more iterative – lots more prototyping, lots more trial and error.

There are a few other interesting conclusions.  CEO’s didn’t do as well as the kindergarten kids either.  However, mix in an executive administrator on team of CEO’s and there was a dramatic increase in results.  Also, it turns out that architects and engineers outperformed everyone (whew!).

So, what can we learn from these results?  When you add in an executive admin to the group of CEO, this new role tended to act more like a coach – they helped facilitate the process.  Architects and engineers still acted iteratively, however, they had superior knowledge of structures and how to apply them to the goal they were trying to achieve.

How can you apply any of this to the way your team works?  Well, here are a few insights (backed by my own experience as well):

1. When on a team, don’t focus on competing for leadership – focus on solving the problem
2. Have clear goals that are the focus of the entire process
3. Work iteratively to achieve your goals.  Realize that there is no single correct plan.
4. Just like the architects and engineers, you should have a buffet of specific knowledge and insight to pull from when needed to help you achieve your goals.  Knowing when to apply certain technical techniques and design patterns combined with an iterative approach is key to achieving even better success than working iteratively alone.
5. Great teams work together – physically.  Think about trying to solve the marshmallow challenge while working with a distributed team.  Would be virtually impossible wouldn’t it.   Distributed teams are a reality of business these days, yet we should really consider how we’re forming our teams.

Of course, there are a lot more ingredients to a great team – however, these are some fundamental characteristics that seem to emanate in virtually any team challenge.

Agile teams are always looking to reduce waste so that they can produce customer value quicker and more efficiently.  For example, the Scrum builds in a meeting called the Sprint Retrospective to give teams an opportunity to reflect on their own efficiencies – allowing them to reinforce practices that are going well, and identify and resolve issues that are causing waste.  Scrum teams also have a time-boxed meeting called a Daily Scrum, which among other things, asks “what are your impediments” to help the team quickly identify things that are getting in their way (aka waste) so it can be dealt with.

In order to understand waste, you must first be able to understand value.  Ultimately, agile teams want to provide value to their customers.  It’s generally accepted that customers find value in working software that they can use to solve their problems.  Therefore, anything that gets in the way of producing working software that customers can actively use should be considered waste.  Based on this, here are a few things that could be considered waste:

1. Fixing bugs
2. Support
3. Partially done work
4. Handoffs
5. Waiting for something
6. Switching between tasks

In a perfect world, we wouldn’t have any bugs or time spent on support.  We don’t live in a perfect world.  Try as we may to completely eliminate these from our world, in reality, the best we can do is to learn from these forms of waste, and try to minimize them.

One very important aspect of almost every successful agile team is their ability to measure. Agile teams like to capture all sorts of metrics about the rate they produce value and the rate at which features flow through the development process.  This information gives them insight into how much value they can produce, and ultimately set the right expectations with the customer.  These metrics can also be used as baseline for process improvement.

So, how can time tracking help?  Most agile teams start by capturing metrics such as “how many story points can be produced by the team in a single iteration / sprint” – the team should of course always want to increase this value by becoming more efficient and reducing time spent on work that doesn’t produce value.  Sometimes, however, you might not understand where the waste is in order to eliminate it.  One way to understand what type of waste to focus on reducing is to capture how much time people are spending on the production of value versus time spent on work that could be considered wasteful.

For example, let’s assume the team suspects that they are spending much too much time on support forums and bug fixing.   One way they can confirm this is by leveraging time tracking to help gather metrics that proves this.  A team can simply capture the amount of time per day in a few basic categories – producing value, working on support issues, working on bugs.  The team can then use this data to form a baseline by which they can continue to improve against.

After taking a look at their time tracking data the team finds out that in a given week of a team of 4 people, 40 hours were collectively spent on support and 20 hours went into resolving critical bugs found by customers.  Clearly, out of 160 potential working hours (assuming there is a 40 hour work week for the team), ¼ of the time is spent on support.   Armed with data, the team can really focus their retrospective meeting on identifying what is causing the support requests.  During this analysis, they find that the installation routine is not robust enough and is causing many problems for customers resulting in calls to the support line.  The team quickly realizes that if they resolve the issues with the installer, support could go down considerably – so they decide to fix this problem and measure the results.   They find that after they enhance the installer they were able to cut their support costs down to 20 hours per week.  This also resulted in the team being able to add 12 additional story points to the week due to the waste they were able to remove.

Time tracking can also help detect when teams and customer expectations may not be met.  Setting expectations, even at the level of a Sprint (which can be anywhere from 1 to 4 weeks long) is more important than most teams realize.  When you set out on a sprint (at least if you are using Scrum as your process), you produce something called a Sprint Backlog.  Don’t take this list for granted…as your customer may see this list slightly differently than your team – they “perceive it” as a promise to delivery something within a small period of time while your team may consider this a list a target.  Some teams don’t release the contents of the sprint backlog to customers for this very reason – however, customers generally like to know what they are getting next 😉  When you make such a “commitment” (and yes, we all know it’s not a true commitment – but more of a forecast with hopes of a small amount of variability) the customer’s expectations become set.  If you under-deliver, an awful thing happens.  You erode a small amount of trust that the customer has with your team.  You start eating away at your Trust Capital.  I’m not sure I can explain all of the psychology involved, but even with GREAT customers, even a small difference between what they expect to get and what they get makes an impact on Trust Capital.  Trust is something you want to build, not erode (like all forms of capital) – so, you want to govern how you plan your iterations around success rather than hope.

Time tracking can give you an early indication that expectations may not be met.  If you’re finding that entered time drastically exceeds estimated time for work, this could be a flag that expectations, and thus trust, may be threatened.  Looking at this form of variance allows the team to have a discussion – giving them an opportunity to try to resolve the underlying issue, make compensating adjustments to approach, or to immediately and transparently reset expectations.  By the way, being completely transparent on a project and pre-emptively resetting expectations also builds trust due mostly to the fact that customers don’t like to be surprised.  Transparency, even when things are going bad – as long as it happens early – works to build trust.

So, in essence, time tracking can go beyond traditional uses and can be a handy tool for teams not only learn from, but to help manage the delivery process.

At a single glance.

That’s what it should take to know when something isn’t right on your projects.

Knowing that something is wrong with your project should be as easy as glancing at a visual indicator.  You shouldn’t have to interpret anything.  You shouldn’t have to be an expert in metrics or project analysis.  You should easily be able to tell that something isn’t right … with a single glance.

Monitor and control systems have been around since the dawn of innovation.  We see these types of systems all over industry – simple and intuitive displays representing the health of a system.  We see this in manufacturing, transportation, energy, and finance.  Of course, different environments use different ways of indicating problems – but all monitor and control systems have some commonalities – they not only inform you when something is “bad” but also when something “could be bad” or is “about to be bad” to ensure that you have an opportunity to do something about it.

This isn’t new in IT either.  15 years ago I remember filling out IBM status reports and at the top, sure enough there were the KPI indicators – Green, Amber, and Red.  Status reports mean well as ultimately, they were put in place to help detect problems sooner rather than later – with the hopes of allowing at a management level to help prevent a possible problem rather than dealing with the mess of the problem occurring.  This is why PM’s (especially those PMP or Prince2 based) are very focused on risk and issues – as these are communication tools that help us understand when risk is turning from potential to a reality.

On modern projects, especially those that use tooling, we should expect a much more real-time and transparent view of our projects.  We gather all sorts of metrics in on an agile project – these metrics providing us that necessary feedback loop required for continual improvement and alignment.

We capture things like velocity – which is the measure of the amount of value a team can produce over a period of time.  We represent progress in charts such as burndowns – that show the rate at which value is being produced against a plan (at different bucket scales such as iterations/sprints, releases, or the product itself).  Simply go to Google and search for “agile metrics” and you’ll see a LOT of information about what you can be measuring, what those measurements tell you, and what to do about it.

(go ahead.. click on this link – it will show you the results)

I’m a huge fan of metrics – I’m a huge number geek.  I feel very comfortable dealing with numbers, interpreting their meaning, and using them as a basis for action.  I commonly point to fancy charts to say “look.. this shows us we’re doing great”.  I love to get into the raw numbers, use pivot tables and graphs to really drill down into a project.

I’m not normal though.

What I realized a long time ago was that we actually needed “single glance” metrics – just like control stations in other industries.    Not everyone has the time and inkling to deal with raw data all day – or to continually interpret numbers and charts to understand if the system is meeting its goals.

On projects that I’ve been a part of we’ve always wanted ways to give us early “smell test” indicators.  We wanted something that would light up when something “smelled bad” on our project.  Perhaps a developer is going dark (meaning, they aren’t surfacing status and are hiding away getting work done), or the expectations we have set with our product owners/business may not be met (we don’t want to know after the fact that we’re not going to ship what we said we would ship).  We needed something that would give us an indicator when things were potentially bad.

Take a look at the following chart…

Now.. tell me.. is what this chart showing you good?  Is it bad?  If you’re mom looked at this chart – could she tell you if things are going well?

When you take a look at metrics on your project, you should consider ways in which you can know that a conversation needs to happen based on a very simple view of your projects – this is especially true when you are managing many projects.  Think of your environment like NASA’s Mission Control Center – you want to see valuable, meaningful information immediately that requires very little interpretation.  You don’t want the system to solve the problem – but you do want your control center to help interpret the conditions that help you make informed decisions as events happen – not after they happen when you don’t have any ability to do anything about it.

Typically, when you are alerted to the problem, you want to know right away what the consequences are.  Systems that alert you to a problem, should also help you understand the potential problems.  For example, if NASA’s onboard oxygen indicator says “low” – you might want to know immediately how low, but also, how much oxygen is left at the current rate of consumption.  Similarly, a good example on a project is an indicator that “the expectations you have set with your customer may not be met” (for example, the burndown rate of your iteration or sprint indicates that at your current team’s velocity you won’t get all of the sprint backlog items complete by the end of the sprint) you might want to know exactly what stories may not make it in order to have the appropriate well informed conversation with your team.

The need for these visual indicators also helps explain the rapid adoption of practices such as Kanban on IT projects – Kanban literally meaning “signal board” – leveraging visualization of flow and indicators such as work-in-progress problems (too much or too little) to help quickly raise the “problem” flag (I talk a little bit about Kanban here:  http://www.infoq.com/presentations/A-Dash-of-Kanban-Anyone)

In addition to the raw project data, you might also look for “subtle” pieces of information that tell you a lot.  Has a developer not checked in code for 5-6 days when normally they check in code every 1 or 2 days?  Has your team been updating their work?  Do they have too much work assigned to them across too many projects and just aren’t letting anyone know?  I consider these “soft metrics” – yet still extremely valuable in helping to detect problems early so that you and your team can have an opportunity to act.

Don’t think that having metrics and fancy charts will be the solution to your team problems.  You must truly understand what these metrics mean and more importantly how and when to act.  This is why I like using tools – as good tooling can help you.  Catching issues, even potential issues, as they happen gives you the insight to act – ultimately helping you reduce overall risk and more importantly help catch and eliminate waste.