An Executive’s Justification for Agile

I was recently working with teams at a client as they transitioned from a traditional project management mentality to one of Agile. C-Suite Executives originally felt comfortable with traditional project management because dates and scope were communicated and they could “abstract” the day-to-day details of that project away, allowing focus on the strategic concerns of business. Delegation is a common tactic of successful managers and is how much of the corporate world gets large initiatives complete.

Often many middle managers struggle going from high performing doers to strategic generalists (Watkins, 2012). The managers that aren’t able to delegate and move up, struggle in their position. So many successful executives work this way – get the details onto the plate of someone else. There are a few problems though, as we know today:

  1. Can the executive trust the date and scope that your project managers are giving you?
  2. Are the executives asking the people underneath them to work very differently from the way they would like to work (delegation of details)?

Many have addressed the first question on trusting date and scope, so I won’t discuss in depth here. But you can certainly look at the success statistics of waterfall projects here and here and come away with a conclusion that, on the whole, bigger projects struggle with waterfall methodologies.

Addressing question #2 is where I’d like to go in this post: Are you asking the people underneath you to work very differently from how you’d like to work?

There are at least two roles that will suffer in this model:

  • From the executive’s perspective, they like to have the details happen elsewhere, but what happens in traditional project management projects is that someone builds a project plan, and then everyone works to that project plan. Team members might be updating their % complete on every task, and that rolls up to total project % complete. In many cases, the project manager manages an all-inclusive project plan, from low level tasks to strategic milestones. That person must be aware of both the details and the high level: a challenge. Compared with Agile or Scrum projects, the team commits to building features and functionality; how they do that is their business. Notice the difference?
  • From a “resource manager’s” perspective, that person is asked often to time slice their individuals and think each and every time how people fit best together to get the job(s) done. I once spoke with a customer that had just moved over to Agile and as a resource manager, he asked the question “Now what? I don’t know what to do with myself.” He was literally busy shuffling people around, but all that stopped when his teams moved to Agile. The shift to a more strategic approach has led to career success.

Let me propose that you think about an Agile transformation or some Agile adoption in your organization as just applying good business/management sense, in the following ways:

  • Delegate the “HOW” to the team itself. Stop having your managers up the chain so involved in the implementation details of your software delivery. This should come naturally to inherent natural managers.
  • Delegate the “WHAT” to someone – preferably a product owner. This is usually a challenge for executives. A project is usually a WHAT and a WHEN, because software is fungible (i.e., it can be divided up nearly infinitely different ways). This fungibility means – you can have a high level WHAT you hold others to account for, but let them make tradeoffs on the details. Normally, your project is not a failure if they did not get that least most important feature.

Now that we hopefully agree that Agile makes good management sense, it’s important to discuss how to get there. You should consider hiring an Agile consultant to assess your specific situations and provide a detailed change management plan. You should also challenge your immediate subordinates to think about “delegation” and work towards that end. Even if you do not adopt (or, implement) a full Agile environment, you will get better results and a more engaged organization, which is a ‘win’ from every angle.


How an Agile Team Can Succeed with Limited WIP

imageOne common pattern of successful agile teams, is they learn to focus and the right things.  They learn to stop spreading themselves too thin.  They learn that limiting the amount of their work in progress leads them to more predictable results. 

I’ve talked about why keeping your WIP (work in progress) even within a sprint is important.  The tool you might use to measure the amount of work in progress is a Kanban board.  You might decide that a WIP limit might be #developers – 1 (3-person team selecting a WIP limit of 2).  Uh oh… you need to be working together.  The big questions that arise are:

· Why is this a difficult premise for many teams? 

· How can you overcome this in a software development team?

Why is Working Together Difficult

From the earliest college courses in the topic, we’re taught to break problems down into pieces and solve the pieces independently.  As an architect, this means solving problems with layers, tiers, and components. As a developer, this means the abstractions of problems and encapsulating complexity inside methods and classes.  As team members, we’ve been rewarded for being the developer that you can “just give them problems and they come back with solutions.”  We even have phrases for people that can’t do that, we say “they need a lot of babysitting.”  There are a lot of messages being reinforced to solve problems separately and work independently.  In short, it’s difficult to work tightly together for many teams because it is in our computer science DNA to avoid being inter-dependent. 

When I introduce limiting “Work in Progress” with a team the first time, it can be awkward.  Based on the downsides of multi-tasking, they typically agree to limit their WIP. Shortly thereafter, though, someone is left out, standing without a story of their own. 

Learning to Work Together Again

Fortunately, there are a few tactical things that we can do to improve our ability to work together again.  Here are a few – in order of my preference:

· Pair Programming.  Literally, put two developers together in front of one keyboard and talk about the problem, solve the problem.  Developers will sometimes take turns coding and watching often.  I’ve seen this work wonderfully, but admittedly it’s scary to adopt if you’ve never done so before.  If you’re not ready for this, keep reading.

· Horizontal Slicing.  If you must have a 1:1 relationship between your developers and keyboards, then try this strategy.  If a user story is a vertical slice of pie, then cut the slice horizontally a few times.  In enterprise apps, we typically have the database, the business layer, and the presentation layer.  Each layer can be a person’s job.  Split them up, and work on them in tandem.  Remember that you need to finish at the same time, not necessarily do them in sequence as if you did when you were alone.  Establish and challenge each other’s contracts and interfaces with your slide – it might make your solution even better.  This is different because you will be forced to come together and make that thing work early and often.  I take this as often a decent side effect.

· Micro-Vertical Slice: If a user story represents that sliver of pie – why not divide it up even more and work on it in tandem together.  Sometimes stories include both the admin side and front end.  Tackle both at the same team, but stay close to each other’s work.  This one will require even more conscious effort because it might be easier to separate and do your own thing.  Try to avoid that.  It’s not as natural as Horizontal slicing and runs the risk again for independent lonely coding again – but with some discipline, I’ve seen this work.

· Rougher-Finisher Pattern: Maybe between a pair of developers, someone is a better sledgehammer person and another is a better pocket knife.  Perhaps have that sledgehammer going and have someone coming back in over again to refine.  Do this only if you both agree it’s equitable and not an excuse to be sloppy.  This isn’t my favorite, but if the other three don’t work for the situation, it might be worth a look.

What If It Still Hurts

Do it more often.  In this world, you’re not doing it right unless you’re stepping on toes a little.

Lean and Agile DevOps with VSTS and TFS 2015

Take a guided tour of the latest features in Visual Studio Team Services & Team Foundation Server 2015 for optimizing your delivery pipeline. We will show you how the products and services will shape your process and enable your teams adopt Lean and Agile DevOps practices.

Key Experiences:

  • Agile work item flow
  • Builds and continuous integration
  • Infrastructure as code
  • Self-hosted package management
  • Release management
  • And much more…

Complimentary lunch will be provided to registered attendees.


Clint Edmonson is a Principal Consultant with Polaris Solutions. He is a technology and process champion who help companies throughout the region incorporate Agile and DevOps strategies into their business to continuously deliver valuable software to their customers.


Date: May 24, 2016
Time: 11:30AM
Event: Polaris Solutions - Lean & Agile DevOps with VSTS and TFS 2015
Topic: Lean and Agile DevOps with VSTS and TFS 2015
Sponsor: Polaris Solutions
Venue: Microsoft Office - St. Louis
Location: 3 City Place Dr, @ 1100
Creve Coeur, MO 63141
Public: Public
Registration: Click here to register.

Welcome to My Newly Launched Blog

Over the past few months, I have decided that my blog needed a little attention.  The focus of what I’m going to 8017202723_b258a5016c_zbe writing about has shifted from deep coding concepts to more of a focus on leadership, the agile movement, and IT organizational strategy.

A lot of folks that I work with tell me why they may not want to write a blog is the reason that they may not feel like an expert and therefore not qualified to be published online.  The phrase, “Who would want to read what I have to say” is a common refrain back at Polaris Solutions.  Acknowledging that own insecurity in myself, I feel like it’s important to share not only the “answer,” or destination – but it’s important to talk through the journey as well.  And to that extent, I consider what I write and share with you to be lessons learned, mistakes, and observations as I grow myself.

Most paramount in my purposes here is that there may be a chance that some of this is something that you, the reader, can relate to.  Possibly you’re seeing some of the same things in your organizations.  Maybe even there’s a chance it helps you avoid the pitfalls that I’ve fallen into.  To the extent that happens is rewarding to me.  If you can relate to anything I write, please feel free to share in the comments.

The Title

Work In Progress is a title that really rings to me.  Rather than any talk of Ivory tower, it’s more important to communicate that this is my goal.  This blog really is a work in progress.  My knowledge in the area indeed is also very much a work in progress.  I am a work in progress. 

The Arch

Admittedly, I root for my home town – St. Louis, MO.  It’s a great place to work and live.  Additionally, I chose to include the Gateway Arch because like Agile, it’s simple and it represents reaching for new heights.  It reminds me that solutions that work don’t necessarily need to be complex – in fact they’re better when complexity is gone.

Thank You

This blog post was written on bluehost, using, with the getnoticed theme.

What Makes Agile Projects Different – Nothing Left on the Table

Imagine you’re doing your taxes. You’ve been collecting receipts, filling out forms, and doing some light math. Then you discover that the deadline is tomorrow morning, suddenly you jolt yourself out of the monotony and move that pen a little faster. You get everything done and breathe a sigh of relief. A few questions about this process:

  • Why were you drudging your way through it before?
  • Why were you suddenly able to sprint your way to the end to get it done?
  • Did the quality of your work change before and after you learned about that deadline?

This is a situation that many Americans can understand. There are plenty of activities in our world where we can turn up our intensity and suddenly turn into apparent “super heroes” in a burst. Many of our colleagues and managers in the software development world, believe that we can do the same when building a software product. What makes this a bad thing to do in complex software, but at least debatably a good thing doing our taxes? Quality. Assessing the quality of light math or collecting forms, filling in paperwork is vastly easier than assessing the quality of software – of which the user experience is but one way to interact with it. Corners can be cut, and often not deliberately at all levels of a software development project, and often they are when the right checks and balances are not in place.

I’m working with a product owner that really struggles with the agile concepts as part of an agile software development project that is literally one sprint away from releasing their software to the world for the first time (with the minimally viable product). This product owner still thinks he can ask the team to “get additional items done” plus all the existing commitments. He’s playing with fire and risking his business in ways he doesn’t yet understand. This is a launch in the making with many hours of input and the team has up until now built quality software at an astonishing velocity.

Waterfall projects often play out that the team has been building software, and a project manager/product owner gets involved and asks for more intensity. Somehow teams often “get it done” but they made choices that the business may not like. They often have to cut quality to get a set scope done by a specific date. Often that quality is harder to assess; and the team moves on and the business celebrates and moves on. Somehow later, the maintenance problems show up, and we all forgot the cause for those issues.

Rather than comparing an agile software development project to tasks like filling in tax forms or other tangible work in the world, it’s a better thing to compare it to a factory shop floor with a conveyor belt smoothly pushing product through the factory until completion. Imagine the engineer has rated the conveyor belt at 5MPH before he believes the wheels fall off. This product owner wouldn’t feel comfortable interjecting and claiming to run it at 10MPH. I imagine that product owner would defer to the engineers that have given him facts on which to make decisions.

Agile projects, with a few characteristics share more in common with that belt than tax forms:

  • Retrospectives done regularly
  • Team builds software with a limited work in progress limit
  • Team has a clear definition of done (requirements, development, testing, and releasing)

If a team has been continually doing retrospectives over the course of the year; it’s already been continually improving. It’s already with a limited WIP, delivering software at a level of quality in a smooth/flow fashion. And if that team has been successful, it’s velocity is predictable.

By definition, the team has left nothing on the table, already. A product owner asking for more is asking for another 10MPH and if the team does that, quality will suffer – just like the conveyor belt and possibly break.

Speaking at St. Louis Silver Linings Conference (Again)

I’m excited about the fall, but mostly this year because of the chance to speak at conferences. I’ll be giving an introduction to DevOps talk at the St. Louis Silver Linings Conference this year. This year, Polaris is sponsoring, helping to organizing, and doing some of the speaking at the conference. This time the conference will be on Friday – 10/30 and will be in St. Louis. For more information – the conference site is at

Don’t Forget to Measure Real Work In Progress

As often is the case when you set out on the Scrum or agile journey as a software team, the team often starts going through the motions. They often work through the proper ceremonies, meetings, deliverables, actions; but what can get lost is the meaning and the ‘why’ we do it. Many teams in fact start doing daily standup meetings as a way to start being agile. The thought there is at least that everyone knows what everyone else is doing. Meanwhile they might still be planning and committing to 15 sprints down into the future (e.g. a waterfall project plan in another form). Sometimes they have split responsibilities such that the product owner is handling the prioritization, but still forcing all of the requirements to be done ahead of time before the sprint starts. Often, I’ll hear the product owner say things like “I’m just giving the team a runway.” I see this a lot and sometimes it seems like it’s working for them; to enable meetings to be fast and efficient, but I’d suggest thinking about work in progress, or WIP in terms of everything that you need to do to bring a feature to “production.”

This one example, might be worth exploring a bit more in depth. As the product owner builds the runway; and encourages the team to groom as fast as they can, it might in fact give the team a false sense of security. Here’s an example Kanban that I’ve seen recently.

The way to read this is that the “3/3” above the active column shows a “WIP Limit” of 3. The team is telling the world that they will only have 3 active at any given time. The good news is that they should be getting things done at a relatively predictable pace.

The interesting, and potentially unfortunate news is the “groomed” state. The product owner has likely had grooming meetings where he or she has presented and had estimates put onto items in the future backlog. The point that I’d like to make is that the “groomed’ state is in fact a work in progress, not just active. The risk that the team faces is that; all those items may be out there to be committed into sprints, but they may change as we learn about the ones we’re doing “now.” A potential waste in the project.

That said, having a groomed status such as this, in my humble opinion has its drawbacks but not always wrong. If the organization is not using higher order concepts like epics or features (above PBI/User Story), doing this does give the organization some idea of long range projection of timeframe assuming velocity is being measured. Unfortunately, that longer range projection has the risk of being taken as a commitment and therefore a waterfall plan itself. So be warned, that’s all.

Come see me speak at the St. Louis Silver Linings Conference on October 30th in Saint Louis, MO.  For more info:


Announcing the St. Louis Silver Linings Conference

St. Louis is hosting the newly minted: St. Louis Silver Linings Conference, a conference about DevOps and the Cloud.

Over the past several years, St. Louis has emerged as a great IT and Software development city. Startups and major corporations have placed their software teams in St. Louis because if its great livability and lower cost of living. As such, St. Louis should have a conference about two of the most important topics in the software development industry: DevOps and the Cloud.

Where: St. Louis University Workforce Center

When: July 10, 8:30 AM

How Much: $30.09 (it is a community conference, and this will cover the costs)

How to Register: – click on Register in the top right.

St. Louis – Polaris ALM Lunch on Agile Testing Success

One of my great privileges is working with a team of such talent and knowledge. I find myself learning something new every day. It’s a lot of fun seeing our team share ideas that help make enterprise software development a better place. This month (March 24th), one of our team mates at Polaris will be talking about Agile Testing Success – and covering how to plan, manage, and execute agile testing. Alejandro Ramirez will be covering how TFS 2013, MTM enables agile and automated testing so that teams can continue to sprint effectively during agile initiatives. Free lunch is included, too! Here are the key details and how to RSVP/Register:

  • When: March 24, 2015 – 11:30 AM – 12:30 PM CST
  • Where: Microsoft Office (St. Louis) – 3 City Place Dr. Suite 1100 – Creve Coeur, MO 63141
  • Register/RSVP: Register Now!

A little bit about Alejandro:

Alejandro Ramirez is a Software Quality professional and Senior Consultant with Polaris Solutions. He has over 17 years of experience working in software in development, testing, and IT governance. His experiences range from small businesses, startups and non-profits, to Fortune 500 corporations in a variety of fields. He is certified in ITIL and Lean. He is also a blogger, speaker, mobility champion, and helps companies incorporate ALM strategies to continuously deliver valuable software.


A little more about the talk:

If you are either planning to or are already practicing agile software development, Team Foundation Server (TFS) and Microsoft Test Manager (MTM) offer you a powerful platform to successfully plan, manage and execute agile testing.

During this free lunch session we will cover in detail the different testing capabilities offered by TFS 2013 and MTM for Scrum and Agile methodologies, and will share what we have learned from helping our clients as they implemented and matured their agile testing practices.

Key Experiences:

•    The evolved role of testing in Agile Projects

•    Iteration test planning techniques

•    Test tracking with TFS and MTM

•    Different approaches to bug management

•    Test automation Do’s and Don’ts

•    Testing metrics that are worth measuring

•    Exploratory testing strategies

•    Best practices & lessons learned in the field

Complimentary lunch will be provided to registered attendees.

Minimizing Work in Progress within a Scrum Sprint is Important, too!


How many times have you heard the following from the testers in a team attempting to be agile?

“There was not time to test at the end of the sprint. We just got most of the features on the last day of the sprint. How are we supposed to test those features?”

Frankly, I think it happens all the time. This is one of the reasons that some teams try to have the testing teams test features in a following sprint. The problems is that so many teams attempt to apply a variant of Scrum that can be called Scrumerfall. Basically, these teams are treating a sprint like a miniature waterfall project like the following diagram shows.

This team is based on a real scenario that I’ve seen. The team had three developers, on the first day of the sprint, they all took a PBI and drove it. But what happened? The variation in completion of requirements and development resulted in really squeezing the testers that were on this team. Sure they were working on test cases and test planning initially, and even participating in requirement meetings. Something obviously wasn’t working very well. For instance, how well do you think Feature 3 was actually tested?

If that’s all we do when setting up scrum teams, we’ve failed. We haven’t allowed testing to happen sufficiently, and we haven’t really built quality into the process. We have limited the amount of work in progress (on paper), but technical debt obviously is growing here no matter what.

An alternate reality of Sprint 23 above is executed by the same team, but we’ve set a WIP (Work In Progress) limit of 2 PBI at a time. Let’s see what happens:

What’s different here? The total duration of Features 1 and 2 shrunk a little bit because I had to double up the effort short term (we forced the team to collaborate on those features, rather than each going in their own directions). Feature three testing also grew in duration which illustrated it probably needed to get tested more even in the first case. Additionally, the team is often performing all types of the functions in there, from requirements, development, and testing throughout almost the entirety of the sprint. The team was increasing its design, build, deploy cycles and having many of those throughout the sprint, rather than just at the end.

At the end of the day, forcing WIP limits can increase the throughput and quality of features that are running through the system.