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 wordpress.org, with the getnoticed theme.

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 http://stlsilverlinings.org

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: http://stlsilverlinings.org/


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: http://www.stlsilverlinings.org/ – 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.

Why Minimize Work in Progress is Important in Software Development

Many years ago, The Goal was written by Eliyahu Goldratt as a business novel to illustrate the fallacies in thinking that companies in a manufacturing world tend to have about how to maximize the profit. In this novel, the protagonist learned how to do so for his plant by applying the theory of constraints. As bottlenecks were identified and solved within a sequential manufacturing process, the flow of the whole system was improved when the group stopped optimizing for utilization, and started optimizing for flow. In this process, the team learned to keep the total work in progress to a minimum, so that as a product was started, they worked to get that piece to completion and shipped as quickly as possible. In that world, inventory was a form of work in progress and that was real dollars to be received if it was shipped.

In software development teams, we have our own form of work in progress. Everything that we spend between requirements and Released Code, is our Inventory. It represents time and dollars that have gone into the process that are not being realized in terms of value for our customers. In the below diagram, everything before Released Code is “inventory.”

This is one underlying reason why Scrum and Agile have taken hold in our software development community. Scrum in particular prescribes a batch size (a sprint’s worth of work) that represents the maximum amount of inventory the team should take on. In general, Scrum teams should have “shippable” software and that distinction between shipped and “shippable” is a compromise because our customers may not be able to accept the software at a frequency of “a sprint.”

Before software is shipped, or deployed to production, represents an expense to the company. Consider the following two cases, one is an agile team, and the other is a waterfall project:

Waterfall Team (18 Month Project, 15 team Members)

  • Requirements Team (3 Members Each Making 80K/Year, 5 Months of Work): $100,000
  • Development Team (8 Members Each Making 80K/Year, 9 Months of Work): $480,000
  • QA Team (4 Members Each Making 80K/Year, 4 Months of Work): $106,666

    In whole, the company has $686,666 of inventory. And if this is a general standard operating practice, they are continually (just in IT) maintaining that much inventory on the books (that’s equivalent to having that many products sitting in a warehouse and not being sold).

Scrum Team (18 Month Project, 15 Team Members (there are two teams)). Below is the amount of inventory the company is holding onto, assuming deployments every two weeks. Assuming maximum amount of inventory below (last day of the sprint).

  • 15 Cross Functional Team Members (2 Weeks of WIP): $46,153

Two scrum teams at any given point have six (6%) of the total inventory being maintained. They then ship their software, and the company can realize value from that software much sooner in the process of building that product. Of course there are caveats here in that a software development product must have a minimal viable product, which is assumed to be less than the total scope. Whenever the scrum teams meet that MVP, the company can start transitioning some of these costs into capital expenditures.

This is not true just of Scrum teams, but teams that apply Lean principals and rely on Kanban boards and release continuously also are taking advantage of the significant savings possible in in this world. Rather than measuring a fixed batch size, they are in fact measuring lead time and time to resolution. Either way, the company again is realizing the value much sooner for their efforts.

So we work to get the boxes out of the warehouse and into the customers hands sooner.

Choosing the Right Level of Communication from Release Management

We leverage Release Management for Visual Studio quite often internally and at client sites to enable them to implement release processes for their organizations. One of the strengths of Release Management is its ability to model moderately complex workflows and approval processes within the enterprise. One of the challenges is to get the right level of communication from this tool. If a group has too little communication then people are not informed when they need to take part in a workflow. If there is too much and people begin to start to ignore it completely. Both of these outcomes result in decreased alignment and harm adoption of Release Management within organizations. This post is aimed at highlighting a common problem and a few solutions for it.

For this post, I’ll be using the following simple environment promotion process (click here for explanations of validation, approval, and acceptance):

Problem: QA Manager is Getting Too Many Notifications

Each Release that is created has a targeted environment. The target environment will indicate how far (from left to right in the above diagram) that release will be promoted if all approvals are made. Typically Development will “automate” validation and approval in the development environment to ensure that the noise to them for doing many builds is minimal. In an environment where any build can potentially make its way to production, this is bound to happen. The development team is in effect shifting the noise to the QA group/owner.

Solution A:

Development team changes most builds to only target Dev, and then if a release needs to go to QA and beyond: Dev can retarget an existing release to QA, or create another release that targets QA.

To retarget an existing build, within Release Management, navigate to Releases (tab), Releases (hyperlink below), Open the relevant release, and click on properties:

After that, simply change the Target Stage of the release, and Release management will prompt you to accept the new target stage.

Solution B:

Development team accepts the notification load by adding a member or members as Approvers of the Dev build when it’s satisfactory to promote beyond.


As this one issue highlights, where users are involved in the release process, a team needs to be particularly deliberate about how communication is handled. Before tools like Release Management, it was largely the responsibility of Development and QA to discuss when the next build would happen. These conversations should still be taking place regardless, but now Release Management will help in that process if it’s helping organize the communication. That will only happen as long as both parties in the example transaction above feel like they are getting a fair amount of communication.




Why Agile Transformations Can Fail: Sense of Urgency

At Polaris Solutions, we work with a number of customers that are looking to become more agile in their software development practices. We often help them move in that direction through adoption of new practices, tools, and roles within their organizations. Scale (the number of people/teams affected) and Scope (the degree of change involved) are the two largest variables that go into planning such a change. The bigger the scope and scale together tend to require more effort in order to ensure that the change will be successful and our customers will realize more value. In order to be successful at agile transformations you need more than agile knowledge and experience, you need to be experienced at managing change.

Over the years, as we’ve been involved in numerous transformations, we’ve noticed several patterns for success and many anti-patterns. In this post, which is the first in a series of posts that I will write, I want to deal with one common way that these efforts can go sideways or fail: Not establishing any sense of urgency.

The first question to ask – is why the transformation is needed? Is it actually an urgent need? Does your team or organization feel compelled to change now or is continuing standard operating practices considered generally acceptable? Before a team or organization is going to change, they will need to recognize the pain of not moving. It has been suggested that human beings change behavior only in response to pain (either emotional or physical), therefore, the greater the actual perceived or actual pain, the more the higher motivation to fix it. This is true for agile transformations as well.

Providing strong focus and investment in “the case” for an agile transformation in the enterprise will pay off many times over. The following are some suggestions to ensure that a transformation gets off to right foot that we’ve gathered from our experiences:

  • Ensure Awareness – I’ve seen too many organizations hope to enact change after 2 weeks of training and never talking again about agile. There are many degrees of education and experiences you can provide a team to illustrate the value of moving to agile. Giving awareness and knowledge can help make the case for agile as it largely makes sense to most team members. “Early and often” is a good rule of thumb when communicating in larger organizations.
  • Identify Champions and Hold
    Outs – The United States military would like to ensure that it has overwhelming force when engaging in battles, and you should as well when endeavoring to change a company’s culture towards agile. You have friends and allies that can be helpful – do not try to lead a change like this by yourself.
  • What Will Happen if We Don’t Change – Answer that question for yourself and for your team or organization. Perhaps the answer to this is “quality issues are causing us loss in customers or contracts.” You can use a combination of logic and reason and emotion to communicate this concept, but I have found that if it can be tied back to metrics and numbers – most people will understand and align with you.

None of these items really have to do with technology or agile in particular, but the people in our industry that help lead these changes need to consider these concepts if their engagements are to be successful.

Release Management’s Traffic Overview Explained

I wanted to write another post to help clear up some functionality in Release Management (for Visual Studio 2013). Many teams that I have opened up Release Management (RM) to see the traffic overview page and wondered how that data is actually calculated. What are App/Traffic/Fail metrics to be watching and why is this important. The pro-tip here is that if you hover over these numbers in the tool, you can see a better description.

Each of your Release Paths (pipelines) are listed down this page. Each of your stages is shown for each pipeline. You can get a sense of how many steps are required for an application to reach its ultimate destination (in this case “prod-client”), which is the right-most stage for any given pipeline.

Under each stage, you have:

  • App – which are the number of apps that have been released to that stage (all time). Note, you can have multiple applications going through a shared release path. If you have two applications that follow the same approval chain and environments, have them share Release Paths.
  • Traffic – Number of releases in the last 5 days to have been released to that stage (or have failed to get to that stage, but attempted)
  • Fail – Number of failed releases in the last 5 days to have been released to that stage.

You should probably see higher numbers on the left than you do assuming you’re like most development shops.

So what can you do on this screen?

If you double click on any of the stages, you’ll get more details about the apps that have been transitioned through that Release Path. It will show you the all-time traffic through each of those stages (more than the last 5 days).