Category Archives: Hi Performance

Video of QASIG Presentation Focused on Managing Quality Debt

I had a great time speaking at the QASIG group meeting last night and met some great folks along with reconnecting with others I haven’t seen in some time. Here is the video of the presentation.

 

Video streaming by Ustream

And the slides

Impediment Monkey Overview Video Posted

If you haven’t already checked out our FREE online service, ImpedimentMonkey.com, then check out this overview video describing what it can do for you, your team, and those that you collaborate with to increase the habitability of your team’s delivery environment and deploy continuous improvement on a daily basis.

Delving into Technical Debt – Cutter Article

The following is an except from the article authored by Israel Gat and myself named “Delving into Technical Debt”:

Many of the findings and the recommendations we make in Cutter technical debt engagements are broadly applicable in concept, if not in detail. There is commonality in the nature of the hot spots we typically find, the mal-practices we identify as the root causes and the ways we go about reducing the “heat.” Granted, your technical debt reduction strategy might dictate investing in automated unit testing prior to reducing complexity, while your competitor might be able to address complexity without additional investment in unit testing. However, the considerations you and your competitor will go through in devising your technical debt reduction strategies are fairly similar.

It is this similarity that we try to capture in this Executive Update. Some of specifics we recount here might not be applicable to your environment. However, we trust the overall characterization we provide will give you, your colleagues and your superiors a fairly good “3D” picture of how the technical debt initiative will look like in the context of your own business imperatives and predicaments.

As a Senior Cutter Consultant, it has been a pleasure working with Cutter to release this Executive Update from which the excerpt cited above is taken. For a free donwnload, click here and use the promotion code DELVING. Let us know what you think about the article in the comments section of this post.

The Impediment Monkey Announcement – Bash Your Impediments!

We here at Agile Advantage are excited about a new product offering that we announced today called Impediment Monkey!

This product goes along with our first product, AgileEVM, to help companies take advantage of Agile software delivery methods at scale for increased business value and reduced risk on project investments.

Impediment Monkey will make removing roadblocks to daily progress fun and effective. Impediment Monkey takes in, notifies, helps in resolving and makes bashing impediments exciting and objective. Additionally, Impediment Monkey will let you assign, follow up, chart trends and even provides services to support your impediment bashing efforts.

Go to the Impediment Monkey web site and sign up to keep informed and potentially become an early beta tester of the product. We are looking for your insightful feedback to make a product that is fun, effective, and provides expertise to the software development industry. Join us in making it happen.

Towards a Push-Button Release

This presentation is being delivered as a 45-minute lecture and discussion for a company-wide tech talk today. It contains 2 case studies that revolve around moving to a push-button release that reduced the whole product company’s release cycles from 6 months to every week and the effects of a “No Defect” policy on a team’s productivity.

Impediment Management and the Agile Triangle

The Agile Triangle, a concept that was discussed by Jim Highsmith in his book Agile Project Management: Creating Innovative Products, describes how teams and organizations can go beyond the traditional Iron Triangle in defining project success criteria. In the Agile Triangle, the traditional project constraints of schedule, cost, and scope are confined to one point of the triangle. Balancing out the triangle are quality and value. Agile software development practices have provided huge innovations in delivery of working software from an internal and external perspective. Practices such as automated unit testing, Test-Driven Design (TDD), and Continuous Integration (CI) have transformed our industry and enabled new go-to-market strategies for the business of software products.

Agile Triange (Jim Highsmith*) adding Software Debt
Agile Triange (Jim Highsmith*) adding Software Debt

When looking at the Quality point on the triangle, this is where I see the realm of Managing Software Debt providing a strategy to support greater value generation within the defined project constraints, as shown in the diagram above. Creating a software debt management strategy involves thinking about feedback mechanisms for each type of software debt: technical, quality, configuration management, design, and platform experience. For technical debt, which tends to be focused on code, we can use tools such as Sonar to provide feedback on changes. For quality debt, we can look at defect containment metrics, bugs escaping iterations and into releases, as a feedback mechanism to trend. Configuration management debt could include the ability for an application to use 2 scripts, deploy and rollback, for all environment deployments and promotions along with monitoring branching in source control for potential integration issues (Sonar is integrating this capability, as well). Design debt can be monitored using Sonar and design assertion frameworks such as TisUgly for Java that I created and never marketed well a couple years ago. Finally, we can monitor the effectiveness of our platform experience debt management strategy based on impediment resolution cycle time or other team and management measurements.

This last point about impediment management is incredibly important and doesn’t get enough attention in the Agile community, in my opinion. In fact, as someone who is experienced in supporting enterprise Agile adoptions for defined business objectives, impediment management can be a critical element of sustained Agile software development effectiveness. When organizations hit a wall with impediments, mostly organizational impediments to delivering increased value to customers, they become susceptible to reverting towards past practices to reduce noise and ignore the effects of these impediments. The diagram below shows how impediment management is a wrapper around the Agile Triangle to support increased and sustained value delivery over time.

Agile Triange (Jim Highsmith*) adding Impediment Management
Agile Triange (Jim Highsmith*) adding Impediment Management

Impediment management comes down to communication. How are impediments raised? When impediments are not within the team’s realm of control to resolve, how does management support their resolution? At enterprise scale, is there a need to provide visibility to more than 1 or 2 levels higher in the organization? If so, how do these enterprise impediments get handled at strategic levels in the organization? What is your impediment management strategy?

Please let us know your thoughts on the relationship of impediment management and Agile Triangle. Also, tell us in the comments section how you see impediments managed in your organization. What is going well? What could be improved? How are they escalated? We look forward to hearing your thoughts and experiences.

Approaching Conflict: Be Honest Then Ask for Help

I talk to people in training classes, in consulting engagements, and when out with colleagues about situations of conflict. There is quite a bit of literature out there about how to manage and resolve conflict. There is one single phrase that I use to provide others guidance on how they can work with others to resolve conflicts:

Be Honest Then Ask for Help

I will give an instance of this from my real world. We were working on a team that I was ScrumMaster on. One of the best developers I know seemed to be having difficulty making it to important meetings and also in meeting commitments with the team. The rest of the team was even starting to notice and voice concern about this person’s contributions. In a one-on-one discussion I first described the situation in an honest way:

“I noticed lately that you are not getting to some of our important meetings and seem to be having troubles keeping up with the work we are working on. In fact, other team members made some comments to me about their own concerns.”

Then I followed this up by asking them what is going on and what we should do about it:

“You have been an excellent team member and this recent behavior concerns me in terms of the team and for you. Do you have any ideas about what is going on and how we should address it?”

Come to find out this person was having heavy family issues over the past 2 months. They were so consumed with these family issues that they were not really aware of how much their behavior was impacting the team. They told me that they would like to talk with the team about their situation before the next day’s Daily Scrum meeting. When they told the team about their situation the entire team was very supportive and said they would help and make up for any impact to planned deliveries if they would just keep the team informed about any adjustments that need to be made to handle important family issues.

Conflict Types

In our Certified ScrumMaster course we provide a list of conflict types:

  • Lack of clarity – we just don’t have detailed enough information to create a common view
  • Position focus – we are discussing a topic from at least two different perspectives
  • Different values – our philosophies or principles are not aligned
  • Past history or personality – our previous experiences or personality trait we are familiar with distracts us from healthy resolution

The first two, “lack of clarity” and “position focus”, make up a significant amount of the conflict that we come in contact with. Fortunately, these are also the easiest to resolve in my experience. When there is a lack of clarity we can analyze more to make visible data that could help us clarify the situation. For a position focus conflict, we can usually find something that all parties can agree on within the larger situation or topic. From this point of agreement we can work through it until we have a sufficient resolution to move forward with.

Now, the last two, “different values” and “past history or personality”, are a bit more difficult. I have been known to be principled in the past and take a stand when I thought that I could be put into a position of being part of something I didn’t believe was good or valuable. The stance I was taking from a value-based position caused the other people involved to get frustrated with me. In these cases, I have found that we can isolate the pieces of the overall situation or topic that make either party take such a strong position and then work on them through negotiation. It can take some time to work through conflicts involving different values. For past history or personality, sometimes we can just try to start anew and take some advice from one our former U.S. presidents:

“Trust, but verify” – Ronald Reagan

Our Book is Available: Managing Software Debt – Building for Inevitable Change


I am quite happy about the book that took much of my time over the past couple years has finally come out. Thank you Addison-Wesley for asking me to write a book. Also, I want to thank Jim Highsmith and Alistair Cockburn for accepting the book into their Agile Software Development Series. Finally, I have to thank all of those that have guided, influenced, and supported me over my career and life, with special thanks to my wife and kids who put up with me during the book’s development. My family is truly amazing and I am very lucky to have them!

Automated Promotion through Server Environments

To get towards continuous deployment, or even continuous validated builds, a team must take care of their automated build, test, analyze, deploy scripts. I always recommend that you have 2 scripts:

  • deploy
  • rollback

And that these scripts are used many times per iteration to reduce the risk of surprises when deploying to downstream server environments, including production. The following diagram shows a generic flow that these deploy and rollback scripts might incorporate to increase the confidence of teams in the continuous deployment of their software to downstream environments.

The incorporation of continuous integration, automated tests (unit, integration, acceptance, smoke), code analysis, and deployment into the deployment scripts provides increased confidence. Teams that I have worked on, coached, and consulted with have found the use of static code analysis with automated build failure when particular metrics are trending in a negative direction enhances their continued confidence in changes they make to the software. The software changes may pass all of the automated tests but the build is still not promoted to the next environment because, for instance, code coverage has gone down more than 0.5% in the past week. I am careful to suggest that teams should probably not set a specific metric bar like “90% code coverage or bust” but rather that the trend of any important metric is not trending in the wrong direction.

Please let us know how your teams move towards continuous delivery or at least continuous deployment to downstream environments with confidence in the comments section of this blog entry. Thanks.