Category Archives: Uncategorized

The Changing Role of Middle Managers

This is an exercise that we run to help understand how manager’s roles change.   This is a re-posting of a session at Agile Open Northwest 2009 [[]].  I opened with stories describing the reality that Senior Leadership is declaring their companies are “going Agile,” and that doing it well presents many difficulties. A potentially intractable problem centers on equipping Middle Managers to be supportive of agility within the business strategy. For sure, their job needs to change from a little to a lot. This is an exercise first described by Pete Deemer [[]].

Defining Middle Managers for this Discussion

We need a definition to continue. In this session we settled on

  • Not Senior Leadership
  • Not individual contributors
  • Intermediaries at any level in between

The discussion of a team versus individuals did not force us to reject this definition as sufficient.

Gather and Process Data

We broke into small teams of 3-5 people and wrote down the “things managers do:” one per sticky note

Next, we had the groups integrate (removing duplicates as we go) their work onto two flip charts labeled:

  • Fine in Agile
  • Conflicts with (or not needed) in Agile

We then reviewed the “Fine in Agile” information. With a bit of work, this could turn into a valid job description.

In the “Conflicts with (or not needed) in Agile” area we realized we could convert this into an action list to change to role of manager for the better.  We also found items that could be re-written in opposite form and included into the job description (e.g. Change “maintain status quo” to “challenge status quo”).

The “Hook”

Then we asked:

  • Would you be more or less useful if your role was like this (pointing to the “Fine in Agile set of roles)?
  • Would your job be more or less interesting if your role was like this?

The majority of everyone who answers these questions would prefer to have a job like the one described on the “Fine in Agile” chart.


  • This can be run with Managers to help them define their new roles
  • This can be run with teams to provide input into the organization
  • Take these to Senior Leadership and HR (Who else?) and help equip the organizations middle managers to support Agile!

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!

Integrating Quality into Portfolio Management

Chris and I presented “Integrating Quality into Portfolio Management” at the BayAPLN last night.  I played the role of Earl and Chris played Geoff in several vignettes that described several conversations at different stages of the most strategic initiatives in the company.

1.  We just finished our annual portfolio planning.  Geoff is in great shape because his Saturn Alpha release went so well.  Earl let’s him know he is doing great and keep it up.

2.  Later (several months) Geoff comes to Earl with a problem.  They need to slip the schedule!  Defects are spiraling out of control.  Earl is so upset because everything is impacted because of dependencies.  Earl yells in helpless frustration, “Just get it done!”

3.  Still later (several iterations) Geoff comes back to Earl.  The goal of every iteration has been “Integrate.”  Dependencies are causing huge problems.  Still, things are better.  Forecasts are converging and it looks like a release is becoming predictable.  Earl wants to know how he can help prevent this in the future because it looks like he will keep his job after all.

Quality bit Earl hard…Strategic Planners and Portfolio Planners must understand quality or schedules will be at risk.  Quality problems often reveal themselves late in release cycles when options are few.

Slides from Managing Software Debt Talk at PNSQC 2009

Tomorrow at 1:30pm I will be discussing my paper published by the Pacific Northwest Software Quality Conference 2009 in Portland, OR on “Managing Software Debt: Continued Delivery of High Value as Systems Age”. I have uploaded the slides for this presentation and I hope that some of the new content will help those looking for ways to manage their software debt more effectively in 5 key areas:

  • Technical debt: tends to focused on the code and reveals itself in duplication and code smells
  • Quality debt: focuses on QA aspects of software development and shows up in growing bug databases and longer regression test runs
  • Configuration Management debt: focuses on integration and release management aspects and becomes apparent with extreme branching and inability to recreate environments from scratch
  • Design debt: focuses on design constructs of components within an application or enterprise infrastructure and is usually difficult to figure out until you are close to a deadline such handling production load
  • Platform Experience debt: focuses on the people in the software creation process and usually involves extreme specialization and waiting on people to finish their part

Without further ado, here are the slides:

Also, here is the picture I use to discuss Managing Software Debt from high level in terms of maintaining and enhancing value of software assets:

Effect of Managing Software Debt to Preserve Software Value

The Forgotten Scrum Elements


I have worked with many individuals, teams, and organizations in the use of Scrum. During that time, I have found that 2 parts of Scrum continually overlooked in implementation. Since Scrum is already a minimal framework, just enough to keep a team out of chaos, when a piece of Scrum is left out problems are bound to occur. The 2 most common parts that I see left out are:

  • Product Vision
  • Potentially Shippable Product Increment

Product Vision

There are times that I work with a project team and ask what they are going to be developing. If the answer involves a list of requirements and the team has difficulty in describing how what they develop will deliver value then I know there is a missing product vision. This happens more often than you might think. If you want to check if your project team has a common understanding of the vision, do the following with the entire team:

Each person on the team please write down what the software we are delivering will do for its users in 1 paragraph. After we have all written a paragraph, each person on the team shares their understanding with the rest of the team.

If while going around to each team member there is another person on the team who disagrees with the part or all of someone else’s understanding, then your team might not have a product vision. At the very least, the product vision has not been communicated well to the entire project team.

A simple way to generate a product vision is to use the elevator statement template from Geoffrey Moore’s book “Crossing the Chasm”. Here is how it goes:

FOR (customer) WHO (statement of need) THE (product name) IS A (type of product) THAT (has this compelling reason to buy/use). UNLIKE (competitive products) OUR PRODUCT (is differentiated in these ways).

Filling out this elevator statement template with the information in parenthesis with the entire product team will help them get a common understanding of the product’s vision. If the product does not have a coherent vision or through the filling out of this template the value of the product seems to be missing, then this could also show that the project team should not be working on the product. If that is the case then the team could start working on something that will provide more value.

Potentially Shippable Product Increment

Many teams decide not to create potentially shippable software at the end of some sprints. It is difficult for the project team to work in a manner that would produce a potentially shippable product increment. This could be because:

  • Roles on the team are too specialized
  • Lack of motivation to work together
  • Product Backlog items that can be completed by only one person on team
  • Doing “Scrumerfall” or “FrAgile” (meaning design/code/test phases within a sprint cycle)
  • etc..

Create a Definition of Done with the whole project team is a first step to working towards potentially shippable software each sprint. The Definition of Done involves all team members agreeing upon what they are able to deliver to product consistent internal quality in the software each sprint. The team will include members with backgrounds in programming, testing, analysis, design, and other disciplines within the software development field. The discussion that occurs in developing the Definition of Done will enlighten each member of the team and provide a way for them to keep on top of their internal quality as feature are being delivered iteratively.

In Summary

I hope that people read this and are able to identify whether they are doing these 2 essential parts of Scrum effectively. If a team does not know where they are headed, day-to-day decisions with an iterative and incremental approach such as Scrum will evolve into a messy implementation with no coherent focus for the users of the software. Getting a product vision and communicating it effective throughout the project team and even to stakeholders can help provide guidance along the way. If the team is unable to deliver a potentially shippable product increment after each sprint then the product will always have leftover work to do in order to get a release out to the users. This work will be to stabilize and pull functionality together in a coherent manner which is usually unpredictable leading to decreased quality and missed dates on delivery. Working on a Definition of Done as a first step towards understanding what is meant by potentially shippable product increment each sprint will begin the process of getting to software that is of releasable quality from the technology even though the Product Owner wants to go another sprint or more before actually releasing it to the users. Also, looking at the Extreme Programming (XP) technical practices to help create software in an incremental manner can help put the Definition of Done into action more effectively in some circumstances. Happy Scrum-ing!

Designing Through Programmer Tests (TDD)

To reduce duplication and rigidity of the programmer test relationship to implementation code, move away from class and methods as the definition of a “unit” in your unit tests. Instead, use the following question to drive your next constraint on the software:

What should the software do next for the user?

The following coding session will provide an example of applying this question. The fictitious application is a micro-blogging tool named “Jitter”. This is a Seattle-based fictitious company that focuses on enabling coffee injected folks write short messages and have common online messaging shorthand to be expanded for easy reading. The user story we are working on is:

So that it is easier to keep up with my kid’s messages, Mothers want to automatically expand their kid’s shorthand

The acceptance criteria for this user story are:

  • LOL, AFAIK, and TTYL are expandable
  • Able to expand lower and upper case versions of shorthand

The existing code already includes a JitterSession class that users obtain when they authenticate into Jitter to see messages from other people they are following. Mothers can follow their children in this application and so will see their messages in the list of new messages. The client application will automatically expand all of the messages written in shorthand.

The following programmer test expects to expand LOL to “laughing out loud” inside the next message in the JitterSession.

public class WhenUsersWantToExpandMessagesThatContainShorthandTest {

    public void shouldExpandLOLToLaughingOutLoud() {
        JitterSession session = mock(JitterSession.class);
        when(session.getNextMessage()).thenReturn("Expand LOL please");
        MessageExpander expander = new MessageExpander(session);
        assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please"));


The MessageExpander class did not exist so along the way I created a skeleton of this class to make the code compile. Once the assertion is failing, I then make the test pass with the following implementation code inside the MessageExpander class:

public String getNextMessage() {
    String msg = session.getNextMessage();
    return msg.replaceAll("LOL", "laughing out loud");

This is the most basic message expansion I could do for only one instance of shorthand text. I notice that there are different variations of the message that I want to handle. What if LOL is written in lower case? What if it is written as “Lol”? Should it be expanded? Also, what if some variation of LOL is inside a word? It probably should not expand the shorthand in that case except if the characters surrounding it are symbols, not letters. I write all of this down in the programmer test as comments so I don’t forget about all of these.

// shouldExpandLOLIfLowerCase
// shouldNotExpandLOLIfMixedCase
// shouldNotExpandLOLIfInsideWord
// shouldExpandIfSurroundingCharactersAreNotLetters

I then start working through this list of test cases to enhance the message expansion capabilities in Jitter.

public void shouldExpandLOLIfLowerCase() {
    when(session.getNextMessage()).thenReturn("Expand lol please");
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo("Expand laughing out loud please"));

This forced me to use the java.util.regex.Pattern class to handle case insensitivity.

public String getNextMessage() {
    String msg = session.getNextMessage();
    return Pattern.compile("LOL", Pattern.CASE_INSENSITIVE).matcher(msg).replaceAll("laughing out loud");

Now make it so mixed case versions of LOL are not expanded.

public void shouldNotExpandLOLIfMixedCase() {
    String msg = "Do not expand Lol please";
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo(msg));

This forced me to stop using the Pattern.CASE_INSENSITIVE flag in the pattern compilation. Instead I tell it to match only “LOL” or “lol” for replacement.

public String getNextMessage() {
    String msg = session.getNextMessage();
    return Pattern.compile("LOL|lol").matcher(msg).replaceAll("laughing out loud");

Next we’ll make sure that if LOL is inside a word it is not expanded.

public void shouldNotExpandLOLIfInsideWord() {
    String msg = "Do not expand PLOL or LOLP or PLOLP please";
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo(msg));

The pattern matching is now modified to use spaces around each variation of valid LOL shorthand.

return Pattern.compile("\\sLOL\\s|\\slol\\s").matcher(msg).replaceAll("laughing out loud");

Finally, it is important that if the characters around LOL are not letters it still expands.

public void shouldExpandIfSurroundingCharactersAreNotLetters() {
    when(session.getNextMessage()).thenReturn("Expand .lol! please");
    MessageExpander expander = new MessageExpander(session);
    assertThat(expander.getNextMessage(), equalTo("Expand .laughing out loud! please"));

The final implementation of the pattern matching code looks as follows.

return Pattern.compile("\\bLOL\\b|\\blol\\b").matcher(msg).replaceAll("laughing out loud");

I will defer refactoring this implementation until I have to expand additional instances of shorthand text. It just so happens that our acceptance criterion for the user story asks that AFAIK and TTYL are expanded, as well. I won’t show the code for the other shorthand variations in the acceptance criteria. However, I do want to discuss how the focus on “what should the software do next” drove the design of this small component.

Driving the software development using TDD focusing on what the software should do next helps guide us to only implement what is needed and with 100% programmer test coverage for all lines of code. For those who have some experience with object-oriented programming will implement the code with high cohesion, modules focused on specific responsibilities, and low coupling, modules that make few assumptions about other module they interact with will do. This is supported by the disciplined application of TDD. The failing programmer test represents something that the software does not do yet. We focus on modifying the software with the simplest implementation that will make the programmer test pass. Then we focus on enhancing the software’s design with the refactoring step. It has been my experience that refactoring refactoring represents most of the effort expended when doing TDD effectively.