Chris Sterling’s Blog

“The team continues to complain about working with that legacy codebase because it has so much software debt. That software debt slows them down in feature delivery and they are wondering if we can push for priority to be put into paying it back some?” asked the ScrumMaster. The IT Development Manager looked distraught about the request. She knew that paying back some of the software debt would be a valuable effort but what would the business say about the priorities? “Tell the team that we’ll start paying back some of the software debt starting in the next release. We must get the current release out the door and a change in priorities won’t allow us to get there.” the IT Development Manager said.

Considering the circumstances I cannot tell an IT manager that this approach is not the right way to go. In many cases the IT manager is not in a position to push for technical priorities even when they will provide value to the business. As teams continue to develop on a system without managing the software debt effectively feature delivery throughput decreases. The following picture shows a team’s feature delivery throughput versus time spent stabilizing each release over time:

There are many reasons for this software debt accrual:

• Pressure of the deadline
• Inexperienced team members
• Specialization
• Over-complication
• Bad design
• etc…

IT management has looked for ways to minimize the effects of software debt. We introduce processes that in theory will reduce software debt but in reality seem not to lessen the effects at all. Tools are introduced that will ease the software development process but we still see similar or potentially new mistakes made by team members. Individual team members are asked to specialize in particular software development disciplines such as Database Administrator (DBA), Quality Assurance (QA), or Business Analysis (BA). Although we do each of these specialized roles more efficiently it seems that the product delivered still is accruing software debt. So what do we do?

It is my experience that teams that adopt agile test and engineering practices within an organization that supports collaboration between business units and development teams are more successful in the containment of software debt. These teams tend to minimize software debt and will at the very least deliver with consistent throughput release after release. In some cases I have seen teams accelerate the velocity of their feature delivery throughput over time.  The following figure represents the problem IT managers have in deciding to manage software debt effectively on existing legacy software:

A team will have to slow their current feature delivery significantly in order to get consistent throughput over time. I would suggest that managing the software debt effectively would be the best decision for a business relying on this software. Software is a valuable asset for businesses that can:

• Reduce costs for business processes by automating significant portions
• Provide information to business quickly so they can make better strategic decisions
• Attain market share providing shrink-wrapped software to meet the market’s needs
• Reduce system decay on existing software assets so they can be used into the future
• and much, much more…

Still, given all of these reasons it is difficult to take on software debt in the wild. We must understand that a typical IT manager has many influences on their decision making, as well:

• Business pressures for a set of features on a certain date for a set cost (The Iron Triangle)
• Expectations of feature delivery based on past software releases
• Unreasonable deadlines due to business issues such as lapsing support contracts and executive management promises
• Perception of their organization and how that reflects on their capabilities
• A compensation plan that does not reward managing software assets for future capability
• etc…

Given all of these circumstances I believe that IT managers are making the best decisions possible. How can we help IT management support our organizational software assets effectively and minimize the effects of software debt? What approaches will allow the software delivery teams to manage software debt while delivering essential features? How can business get more involved and increase understanding of this dilemma that will affect the organization’s capabilities over time? I am interested to hear from anybody who reads this. What are your suggestions?

1 Comment »

Last week I was invited to participate in a LAWST-style workshop on Technical Debt. I was honored to be there with such a great group of people from diverse industries and experiences.

Preface: I am writing this blog entry for myself and therefore it may not be as useful to those reading. Also, the perspective on discussion points are from my own understanding. I will link to other portrayals, blogs, and articles on technical debt in the future to round out these understandings. I do have positions on this topic that I have talked about in earlier posts, conference presentations, and in articles that I will continue to build upon in the future with influence from people in the workshop and outside, as well.

On the night before the workshop began, a large group of the participants went out to a Grand Rapids, MI watering hole to get introduced and start lively discussions. I learned some interesting nuggets such as how some roads in Texas are paved cow runs. We also discussed more of the philosophical and metaphorical underpinnings of the term debt in relation to technology artifacts. One item I took away from this was around discretionary income. Some technology shops either do not have discretionary income or choose to use it developing new capabilities rather than investing it to minimize their current technical debt.

Nancy Van Schooenderwoert provided me with many good pieces of information. While discussing our agile coaching experiences with teams she said:

“The only question that matters at the end of an iteration is ‘Did you build more or less trust with the customer?’”

Some people who read this may find this difficult to find true but I have found this question is important to ask each iteration. Scrum and other agile frameworks attempt to build trust between parties that may have played the blame-game with each other in past projects. As a team and customer build trust the motivation of the team and willingness of a customer to collaborate grows stronger. These characteristics enable faster product development with higher quality.

Now for the play-by-play of the workshop itself.

Rick Hower: 10 Warning Signs of Technical Debt

Rick facilitated a brainstorming session to gather warning signs of technical debt in your code. We brainstormed way more than 10 warning signs that I did not write down. Rick and potentially other participants will be writing an article to choose the top 10 warning signs that I will link to once it comes out.

Matt Heusser: Root Causes of Technical Debt

Here are some of the notes I took on Matt’s topic:

Typical training in computer science tends to not entail testing, maintenance of your own code beyond an assignment, or team interaction.

Technical people tend to take a victim position when developing code too fast creating technical debt. For instance “those mean business people pushed me around and I have no power to change their mind”. Non-technical people don’t always understand what they are asking for when making decisions on feature delivery. If they knew the impact of these decisions they may decide to pay off some of the technical debt before investing in new features.

North American businesses tend to look for short-term versus long-term results. This could impact planning and delivery since the short-term goals may be hacks while long-term results show decay of software can be costly.

Engineers have observable physical reasons for qualifying assessments (ie. “This bridge will take traffic going 40 mph”). Software development organizations do not seem to have these types of qualifying assessment tools fully figured out yet. Matt used mechanical engineering in the 1800’s versus electrical engineering during the same time period to support this idea. Mechanical engineering was well established in the late 1800’s yet electrical engineering was still in its infancy. Useful units to measure were known for mechanical engineering yet the electrical engineering folks did not have similar units of measure. Over time the electrical engineering discipline gained new knowledge and developed useful units of measure that we use today. Maybe we as the software industry are still trying to find our useful units of measure.

David Walker: False Starts

Misuse and bad deployment of practices hurts an organization.

David mentioned an organization that may be of interest: ACQ (American Society for Quality). They have a topic on their site called ECQ (Economic Case for Quality) that may be a helpful talking point.

Chris McMahon asked the question “Why would you not do excellent work?” in a discussion on technical people asking for permission to work on technical debt in their software development efforts. I thought this was a great question so I wrote it down.

Steve Poling: Technical Debt is Fascism

Steve got our attention with the name of this topic. Steve wanted us to come up with formulas we could use to calculate technical debt. I thought he had some good ideas and I hope he is able to develop formulas that actually work for particular instances of technical debt.

Steve brought up Godwin’s Law: “As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.” I thought this was interesting since the term technical debt could be dilluted in its usage if it covers too much of a spectrum and is not able to be pinned down.

I thought Steve brought up a fairly good metaphor for technical debt revolving around his trailer hitch. He had noticed the need to paint his trailer hitch for some time in order to protect it from the elements. The problem was that other pressing items of business came up and he did not paint the hitch. Over time he went to paint the trailer hitch and now it had rust on it. This meant that the total effort to protect the trailer hitch from the elements had grown exponentially. He now had to clean the hitch and make sure the rust was gone and then he could paint it.

Ron Jeffries asked to draw a picture on the black board to discuss technical debt and he came up with what I thought was an amazing representation of the issue. Here is my attempt at recreating his phenomenal chalk talk in a tool:

We can make incremental progress on a large feature area within a system adding value with each addition. In order to make incremental progress we should keep code clean and easy to change so the addition of more features on top of existing functionality does not slow down. In fact we should be able to deliver features faster on top of each capability already built into system. This does not always (or even usually for that matter) happen in projects and instead we end up with a “big ball of mud” to work with. As a team is working on this system they begin an effort to add a new feature and get caught in a quagmire of old crusty code that is difficult to work with. What is even worse is when there are external dependencies to this big ball of mud that makes changes even more risky than it would be on its own.

David Christiansen: Where did all this $@#% come from?

David was entertaining and provided some instances of what he constituted as technical debt. Here are the sources he listed in the presentation:

• Taking shortcuts (experienced)
• Hacks (beginner)
• Geniuses (overcomplicated)
• Living in the now
• Futurists
• Time
• The Iron Triangle
• Anticipating reuse
• Documentation
• Innovation
• Trying to avoid technical debt

Some people in the room thought this list went well beyond what technical debt should be. This list seems to cover almost anything that causes software to become difficult to work with. It was a great list of issues and David went on to say he wasn’t as interested in defining technical so much as help to create tools and practices that would minimize bad software.

David also discussed how documentation is a gamble:

“Like a slot machine the house always wins. Sometimes you get a winner but most of the time it is a loss.”

I will probably use this quote in the future with proper acknowledgements so thank you David.

Brian Marick said the following during the questions and answers portion of the presentation:

“Debt is a property between the people and the code.”

I thought this was interesting and already have multiple thoughts on how this can be applied. I am not sure what is the best way to view this statement yet I found it important enough to write down so I will think about it some more. Also, I hope to ask Brian more about this point in the future.

Michael Feathers also brought to the group a point about the tradeoffs made in terms of “navigability versus changeability in the code”. Some technical folks like code navigation to be explicit and therefore have difficulty reading strongly object-oriented code that separates implementation from interfaces to support change.

Nancy Van Schooenderwoert: A Garden of Metaphors

Nancy proposed that we could start to explain technical debt more succinctly if given a combination of a metaphor and metrics. The metaphor can help people who are non-technical understand the impact of their decisions on technical artifacts. For instance the use of the word debt helps people visualize the problems with just making it work versus craftsmanship (word brought up by Matt Heusser that I thought was useful). She mentioned that technical debt is about expectation setting.

NOTE: Nancy wrote to me and added the following comment - “Metrics and Metaphor have opposite weaknesses so they support each other well. People can be suspicious of metrics, because there is an infinite choice of things to measure and how to measure them. Metaphor, on the other hand rings true because of familiar experiences the listener has had. The only problem is that it depends on tech debt *truly* being like the thing in the metaphor. We have to check back with reality to know if that’s the case. That implies we measure something to see whether and how the behavior of tech debt is different from the behavior of financial debt (or whatever else we used as metaphor).

I think some of the most useful metrics to start with are
* value stream mapping
* bug metrics
* story points delivered, and remaining to be done”

Nancy also brought a great alternative metaphor to debt based on Gerald Weinberg’s “Addiction” trigger responses. Sometimes decisions are made for short-term results without understanding their long-term effects such as in alcohol, smoking, and other drug addictions. To enable better responses to the addiction we must setup a more appropriate environment that allows proper responses to made within. Here is my portrayal of the “Addiction” metaphor drawing Nancy put up:

The “Environmentalist” as a metaphor was also brought up by Nancy. In life nobody has to pay for the air we are dirtying up. Economic systems poorly reflect environmental quality and this has helped lead to issues we are now faced with in global warming.

David Christiansen: You’ve got a lot of Technical Debt, Now What?

I don’t have any notes about David’s talk but Chris McMahon mentioned something I thought was wonderful:

JFDI - Just #%$ Do It

We got to this point when people started asking why wouldn’t a technical person just fix the issues when they seem them. Chris discussed an example of how they decided to use Bugzilla. One of the developers got tired of the old bug tracking system, and he JFDI by installing Bugzilla. It was pointed out that there are also examples of JFDI backfiring and I can think of a situation that impacted a team for multiple days because of JFDI.

The visibility into each task that a person takes on in some organizations makes this approach difficult to follow. How can we help people decide to make the right choices while developing software in these environments?

Matt Heusser: Debt Securities

Matt brought up the term “moral hazard” to describe how technical people act based on their insulation from the long-term effects. For instance, a person may take a shortcut in developing a feature since they are not going to be working on the code 1 year from now when it must be modified to support a new feature. Matt pointed out two practices that may help minimize this effect:

• Customer close to the Team
• Agreement on how to work together

Chet Hendrickson pointed out that a good way to minimize the problem with moral hazard is by:

“Lowering the threshold of pain”

For instance, Chet brought up doing our taxes. Yes he could incrementally update his taxes 2 hours each month. Instead he waits until 2 weeks prior to get his tax forms completed because the potential headache of tax evasion is strong enough that it crosses a threshold.

Brian Marick: Market World

Brian defined the term market world as:

“Get as much for as little”

He then described the term social world as:

“Transactions are not accounted for”

Brian discussed that use of the term “debt” as a talking point may push us into a “market world”. This could be problematic since it leads to the creation of technical debt by only doing enough now to get it out the door. Maybe we could do more to introduce social aspects into the talking points for removing what we now call technical debt.

Brian is a tremendous thinker, IMHO. He brings creative and profound discussion points to the table. Here is one such point he made:

“Agile teams care deeply about business value…the problem with agile teams is they care more about business value than the business does.”

Being an agile coach has lead me to believe this is true many times over. I wonder if this is something we can work on as an industry and should we move more towards social world ideas to identify the right vision for our software delivery focus.

Rob V.S.: Developer in a Non-agile Environment

Rob pointed out some points about development in a non-agile environment. Here are some of those:

• Many developers, for some reason, want to appease customers with their time estimates
• Rob saw this appeasement was causing problems for him and others in the code
• Rob decided he would start buffering estimates to incorporate refactoring into his processes
• A problem occurred when refactoring was causing implementation times to shorten and making his estimate buffers unnecessary
• Rob was finding that he was able to implement features in about 1/2 the time of others now that he was refactoring code
• To his amazement the refactoring worked every time even though it felt like a risk each time he thought about it in his estimates

I thought Rob’s story was a great addition to the group. Not everybody, maybe not even a majority, of the people who participated were involved in projects that were using an agile framework.

Michael Feathers: Recovery

Michael explained that he saw that the industry was talking about people issues more often today then before. This seemed like a good thing yet he wondered when we would get back to discussing technology issues. Chris McMahon said the following that I thought was a good principle to follow:

“Make the easy things easy and the hard things possible”

I am not sure where I heard something similar before but Chris brought it up so quickly that I attribute it to him until further notice. (NOTE: Chris said “as far as I know originated as a design principle in the early days of Perl development. I was quoting Larry Wall.”)

David Andersen: Business Models

David pointed out something that I discuss often in training courses on Scrum:

“IT as a cost center versus a profit center”

I was quite interested in this topic and see this as potentially the most important software development environment problem to be solved. Yet the problem may be so large that finding a solution may be near impossible. Therefore I have found discussing the issue one organization at a time sometimes helps.

David expressed that companies who work in a time and materials approach tend to be cost centers. The idea is that we employ a warm body to take on the work. Those companies whose approach is a service for a fee tend to think like a profit center. The right people will emerge and deliver the services based on setting up the proper relationship.

Brian Marick brought up a reference to the Winchester Mystery House that is filled with all kinds of oddities. I can’t remember why he brought this up in terms of business models but it could be something to think about when discussing technical debt and its potential ramifications.

Matt Heusser: Clean Code and the Weaker Brother

Matt presented the idea of the weaker brother and it caused me to take another perspective look at team composition. At least it gave a strong analogy to draw from for conversation about it. One thing that I thought was interesting about Socialtext, where a few of the folks including Matt work, is they are truly distributed as team members. They have communication tools that help them minimize the potential issues with fully distributed team. One of the tools and processes they use is every commit message to source control goes to the development email list. Something that happens in response to this from time to time is other people on the team can challenge the implementation and a healthy, respectful banter goes on that improves quality of the overall software. I will take this away as a talking point on distributed teams and may even use it on one of our projects in the near future to see how it works for us.

Chris McMahon discussed a policy they had at a previous employer that said everyone must work on a team at least 1 week per month, even the iteration leader (similar to a ScrumMaster role). I will have to think about this policy and its ramifications but I truly believe that I must work on a team every once in a while to keep my practices up to snuff.

Michael Feathers: Topic of Unknown Origin but Greatly Appreciated (my own words)

Michael had a question that I thought was interesting:

“Would the world be better if all your code was gone in 3 months?”

The answer to this question for your particular project context may help the team decide what the effect of technical debt is today. I had a couple of comments on the subsequent discussion points but never got them out because there were so many passionate people with great points, ideas, and questions. Here are the points around taking an incremental improvement to these codebases from my own experience with some horrible situations:

Abuse Stories - Mike Cohn brought this up during a presentation and they were not in his slide materials.  He has since added them and I believe them to be greatly important and easy to implement types of stories to describe the cost of not addressing what are usually technical debt or more likely architectural features. You can follow the link to an old blog entry I posted on this subject.

“Finding a common enemy” - I find teams are not usually motivated until they have a common purpose. One way to find a common purpose quickly is to find a common enemy. This may be a competitor’s product or another team (I hope not but hey?). This can bring a team together and focus their efforts to defeat the competitor. I have heard of companies who developed this focus and cornered their marketplace in a fairly short timeframe. This could also help to address technical debt since those issues will be fixed in order to continue on the path to defeating the common enemy.

Michael did a great job of describing how companies may not consider the value of their existing software enough. Code has value and organizations who understand this can make better decisions about how they treat their software assets. The idea is to prevent devaluation of a software asset when appropriate.

Ron Jeffries & Chet Hendrickson

OK, now this was fun. Ron and Chet put on a artistic show that put technical debt into a perspective easily understood, IMHO. I will attempt to recreate their drawings and the reasoning behind each one but I hope they write an article on this soon since they are incredibly apt to delivering a message succinctly.

As a team is building a system their velocity will either stay fairly consistent, decelerate, or accelerate.

Each feature implementation is developed using a combination of available system capabilities and newly developed capabilities.

A team can choose within their current envioronmental context to build a rats nest that is hard to work with later or a well-designed system that more easily changes with new business needs.

The punch line, from what I could gather, was the use of a negative term “debt” may be problematic from an emotional point of view. Rather than using a negative to discuss the topic it may be better to discuss how we can build upon what we have. Thus we can call technical debt something like “liquid assets”. We can use our existing code to develop new capabilities for our business quickly and with lower cost then doing so from scratch. I am not sure if this term will stick but I like the building upon what we have already developed point of view.

Chet and Ron also brought up the 4 basic principles of simplicity in code by Kent Beck:

1. Tests all run
2. No duplication
3. Expresses all design ideas
4. Minimize code

* These are in order of importance since each of last 3 are potentially in conflict with each other.

Wrap Up

There is so much more that I didn’t take down, remember, potentially understood the importance of, and whatever else that stopped me from recording it. The above content may seem somewhat haphazard since I did not create a coherent overview but rather just recorded what I heard from my perspective. I hope it is still something that others can get some ideas from and use effectively. Lets start reducing technical debt for the good of our organizations and customers and the morale of our team.

3 Comments »

While coaching teams I have found the creation of a Working Agreement as an essential step for a Team to initialize their adoption of an agile framework. I have also noticed that the ideas behind along with the process of creating a Working Agreement is not widely understood by coaches, ScrumMasters, and team members. Although there is no single reason or way to facilitate a Team in the creation of their Working Agreement, here is what I have found to be helfpul.

As a facilitator you can help the team understand the reason for creating a Working Agreement by discussing the need for understood team norms because agile frameworks involve increased collaboration. Becoming a Team involves commitment to working together and supporting each other in our common goals. This commitment is supported by writing what all team members believe are important protocols for the Team to comply with to maximize their capabilities to deliver faster and with higher quality.

With Scrum Teams I have found the following topics are a good starter list to start the creation of a Working Agreement:

• Time and location of Daily Scrum
• Testing strategy (unit, functional, integration, performance, stress, etc…)
• Build and infrastructure plans (shared responsbilities)
• Team norms (be on time, respect estimates, help when needed, etc…)
• How to address bugs/fires during Sprint
• Product Owner availability (phone, office hours, attendance in Daily Scrum)
• Capacity plan for initial Sprint(s)

A common way that I facilitate is to put these topics on a white board or piece of easel pad paper and then ask the Team(s) to create their working agreement with these as guidance. If they find other topics which are important please add them to the list. I highly recommend creating a Working Agreement for your Team. It helps all team members understand what are common protocols for the Team and an opportunity to work through conflicts in practices.

1 Comment »

At a recent Seattle Scrum users group meeting I presented on the topic of “Managing Software Debt”. Here is a link to a PDF of the presentation and the following is a description of the topic:

The Product Backlog in Scrum is used to prioritize implementation of features into software based on value. A Product Owner is charged with managing the Product Backlog to direct software implementation for the greatest possible Return on Investment (ROI). Entirely feature-based Product Backlogs do not consider the decay of software over time, and the resulting software debt can sink a project or company. This presentation will highlight ways Scrum Teams and Product Owners can work with stakeholders to manage software debt over the life cycle of the product.

1 Comment »

Michael Krigsman provided an interesting variation of why blind dates so often fail and changed blind dates to project plans.

The interesting piece to me is the overlap area identified as “rare”.  I speak to many folks about their project expectations compared to plans and one phrase which comes up often is “well, it worked in [name of] project fairly close to plan”.  The somewhat rare success in planning up front seems to be a beacon for further use of particular project planning tactics.

I am not going to expand right now on this subject but I would like to leave this with something for us to ponder.  How many of your projects actually get even close to original plan expectations?  What methods in planning are actually adding to the success?  What types of projects are finding better success?  Let me know if you have any comments or wish to share your answers with the readers of this blog.

No Comments »

Many of you may have heard of Planning Poker for estimating your Product Backlog items. Each team member gets their own set of cards with sizes identified on them in either story points (1, 2, 3, 5, 8, 13…) or t-shirt sizes (XS, S, M, L, XL…). The Product Owner tells us about one of their Product Backlog items they wish us to size in effort and complexity. The team members then choose what size they believe the item to be and once each team member has chosen their card they flip them around. The team must come to an informed consensus on the size of the item in order for the estimate to be final.

As an Agile Coach, I have been working with many teams for some time now on using Planning Poker for their estimation of Product Backlog items. Over time we have identified some “tells” that the Product Owner gives to team members to influence the estimation activity. The three most prevalent in my experience are the Jazz Hands, But-But, and most often used of them all Its Just.

Jazz Hands seem to come out when a Product Owner is describing a Product Backlog item they are excited about and hope will be able to make it into the next iteration. In order to show their excitement about the item their hands raise up near their chest and wave quickly back and forth. This physical display alerts the team members that this item is important to the Product Owner and we may be asked to implement this one quickly. If a team is not comfortable in looking beyond the Product Owner’s physical display to honestly estimate the cost of the item they may be influenced to size it small enough to fit into an iteration and risk not meeting their iteration commitments.

Once a team has come up with either an initial or secondary estimate show of cards the Product Owner may be caught off guard by the size this team has come up with. A common response from the Product Owner may start with “But, but…” which alerts the team that the cost is too high for the item in the Product Owner’s eyes. Although we have coached the Product Owner to respect the estimates made by the team they are unable to sit quietly by when such an event occurs. If a team is pressured by the Product Owner’s response to decrease the size during another round of estimating then the Product Owner will not get an honest cost and this items inclusion into an iteration may be fraught with risk.

Sometimes prior to the initial estimate by the team or directly following a But-But you may hear the notorious words Its Just. These two words usually indicate that the Product Backlog item in question has tremendous value and plenty of hidden work underneath it’s simple facade. The team should be wary of such phrases and enter the Planning Poker rounds with extreme caution. If the team members do not express the hidden work to our anxious Product Owner then the entire team may underestimate the item and get caught later in the software delivery life cycle with a humongous Its Just item on their hands. The team should take the time necessary to fully understand this item and its implications in the Planning Poker estimating discussions.

It is important for teams to own their estimates and take responsibility for their implications. It will not always be easy to give your estimate to the Product Owner. The Product Owner is looking for ways to maximize their ROI for the system under development. The team’s estimates are used as a check and balance to the Product Owner’s pursuits. There are times when the team hears one of the “tells” described above and then may engage the Product Owner in finding out a simpler acceptance criteria for the Product Backlog item in order to better meet their needs. Be careful not to ignore such “tells” though. It may lead to discontent for the Product Owner and the team later down the road.

2 Comments »

In a recent Certified ScrumMaster course that I taught in Seattle we conducted an exercise where a group drew a series of pictagrams describing what a ScrumMaster should not do. One of the groups drew the following picture:

While debriefing the exercise with the entire class a comment caught my attention:

“What is that supposed to be? A ScrumMaster should not go fly fishing for cattle?”

The entire room broke into laughter. The group that drew the picture informed us that this was describing how the ScrumMaster should not use a whip to get things done. I immediately wrote down the comment and it became a theme throughout the rest of the course.

That night I actually spent about 30 minutes trying to figure out how this comment was relevant to the ScrumMaster role. Here is a short list that I have come up with so far:

• Instead of “A dead ScrumMaster is a useless ScrumMaster”, this phrase could be used to describe how trying to tackle issues fully before those involved are ready can be dangerous, may get results you are not looking for, and will not help the team improve.
• It could also be an example of fixing impediments without understanding what the actual root cause is.
• Or pushing practices onto the team without considering the highest priority impediments or when the team is not ready for the changes involved.

Some of these may be a stretch but I have found the exercise to be beneficial overall. It has allowed me to think deeper about Scrum and the role of the ScrumMaster. On top of that it was fun!

If anybody is reading this blog entry out there, I would like to hear your ideas about what the phrase “ScrumMasters should not go fly fishing for cattle” could be relevant to Scrum. Please add comments to this blog entry and I will look at and accept comments soon after they come in.

5 Comments »

One of the aspects of Agile software development methods that I believe is not well understood is the discipline it takes to implement and continue the use of good practices. Writing the test first, managing your build scripts effectively, and communicating impediments in the Daily Standup are all examples of areas which can slide as difficulty arises. This slow decay of our development processes I would like to coin as “Emergent Misbehavior”.

In the Principles behind the Agile Manifesto the last principle declared is:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As a reader of this principle I may be initially believe this to mean look at your problems and find ways to fix them. In this interpretation “problems” could be processes which are not working well. One issue with this interpretation is that it does not take into consideration what the team is doing well and could make improvements to. As teams continue to reflect only on their problem areas rather than how their entire process of software development can be improved they may slip backwards on their current capabilities and discipline. Below are some real world examples of “Emergent Misbehavior” that I have witnessed.

Daily Standup Now Every Two Days

A few teams I have worked with were having trouble understanding the value of a Daily Standup. As an Agile Coach I found it my duty to find out what in their processes and environment was causing the Daily Standup to be of little value to the team. Here are a few of the issues which emerged during reflections with the teams:

• a project manager who was questioning each team member about how they used their time yesterday
• Product Backlog contained disconnected items which were divided up to team members with specific capabilities and therefore team members were not interested in what others on the team were doing
• focus on updating the Sprint Backlog in a tool and questioning estimates of the team members
• managers attending Daily Standup and then “managing” team member based on impediments or discussion points they raised

In many instances a “smell” which was observed around Daily Standup value was team members feeling like they are being micro-managed. The teams interpreted their issues as their providing status every day was more of a distraction than valuable use of their time. Most of these teams initially dealt with these issues by conducting the Daily Standup every two days or twice a week in some instances.

Mini-Waterfalls Inside an Iteration

The incremental nature of Agile development methods are extremely difficult to master for teams used to Waterfall. As a team progresses from Sprint to Sprint and begin to “commit and deliver” on a regular basis they may be finding new processes for their software development. Some new processes that they may enact are:

• Finish each Product Backlog item including design, code, and test before moving onto the next item brought into an iteration plan
• Cross-functional team members working together on the initial functional test scripts before implementing the code and regression test suite
• Build and Integrate all system components on at least a daily basis
• Write failing unit tests before writing the code that fixing the failing test (Test-Driven Development)

As the codebase becomes more complex and potentially incorporates more integration with other platforms a team may slowly digress to what they knew before implementing an Agile development methodology. Some teams find that ambiguity in platform design means they must document the full design of all Sprint functionality before implementing any code. This reaction may be due to found rework, a failed design, or platform change issues such as database modifications or versioning. Rather than better understand where the ambiguity and problems in changeability are manifesting themselves the team is moving to a method which causes other potentially damaging effects.

Other teams may be having trouble getting a potentially shippable product increment completed each iteration. The team finds that time for QA is inadequate and therefore they institute a code complete date a few days before the end of the iteration. Problems created by this small process change may not show themselves for many iterations when the team is again having issues delivering on the iteration commitments. They may ask why QA team members are taking so long to do their testing or the team may decide to move back the code complete date an extra 1/2 or full day. This has now impacted the amount of business value the team is able to deliver each iteration since they have fewer days to code functionality.

Pressing a Team for Productivity

“Better, faster, cheaper” is a reasonable montra for many businesses. Emphasis on “faster” and “cheaper” without the “better” tends to cause decay in team productivity and product delivery. Product Owners may start out excited about their newly found control of directing product delivery but they can evolve as Mike Cohn points out in this article. This evolution may involve the question “How can we make the team more productive?”. The emergent misbehavior in this case may be falling back on traditional methods to get “productivity” in software environments. These include:

• Pressing the team to take on more work each iteration
• Incentives for working harder/longer
• Questioning team estimates on Product Backlog
• Introducing “stretch goals”

Any one of these may “work” at first and therefore act as confirmation to the Product Owner and/or managers involved in implementing the tool for gaining “productivity”. More iterations go by and quality issues start to arise which are now affecting the team’s ability to deliver even equal to iterations just before instituting the “productivity” gaining tool. The team have been meeting the expectations and incentives by giving more features but with less quality therefore accruing technical debt. Using these traditional methods for increasing a team’s productivity has backfired and now we must pay up the debt which is more costly than it would have been dealt with over each iteration.

Team Leaders Taking Over Team Responsibilites

Agile development methods tend to profess incorporating the thoughts of all team members in decisions based on informed consent. For anybody who has worked with people discussing a divisive issue and looking for common ground it is well understood how difficult consensus can be to achieve. Many issues do not cause the divisions on a team which could break down consensus building.

When an issue does arrive that is not so easily discussed and worked through then a team could jump back to traditional methods of decision making such as seniority or team leader wins. This decision making may not initially or ever cause negative effects if it happens on an infrequent basis. But if this type of decision making continues on a more regular basis it could cause some of the following issues:

• team members who will not speak up about their ideas
• task mastering by team lead or development lead
• lack of responsibility from team members for software delivery
• team members waiting for team lead or development lead to approve all work

These team problems could decrease or cap team productivity, demoralize team members, and make delivery on team commitments less predictable.

Tackling Emergent Misbehavior

In my experience, most of these and other emergent misbehaviors are the result of not fully understanding the causes of process challenges and taking the most easily available fix. The root cause of a challenge is not always easily apparent and may involve asking questions such as:

• When did this process challenge start?
• What variables could have been involved besides those that are obvious?
• Could our environment be changed to support a better result?

The answers to these questions may drive better insights into the actual root cause thus giving the team better information upon which to derive solutions from. Look out for Emergent Misbehaviors in your Agile software development process and use the retrospective not only to look for problems but also slippage in current process discipline.

1 Comment »

On many occasions as a trainer, consultant, and coach I am asked “if in Scrum the team is self-organizing how do we handle team and individual performance problems as a manager?”. From my point of view this question has multiple components that must be treated separately.

What is a “Team”

It takes more to form a team than slapping a group of individuals together and calling them a “team”. Teamwork can grow within a group of individuals who have a common goal and personalities which lend themselves to team building. As a manager we cannot make a team productive, we can only setup an environment to enable productive teams. So how do we setup such an environment?

Shared “Resources”

To start off with, people are not “resources” and the use of this word has been problematic for many organizations. Discussing people as resources gives management the idea that people in their organizations are interchangeable cogs that can be swapped around to meet needs in a reactive fashion. For instance, “we need Joe, who is knowledgeable on that particular application, so we can put Jennifer in his place on that project”. This assumes that Jennifer has the domain knowledge, context, background experience, same competency levels, and personality as Joe. Of course this is not true and therefore we may need to do some mental gymnastics to rationalize this transition but such a transition always has unplanned effects. To be fair, at times it may end up a net positive for the team and product delivery. The assumptions made do not support a predictable result.

In software organizations there may be a need to share “specialists” until their knowledge is shared to enough people or the specialized tool in question is minimized or eliminated. This situation has developed over time in many cases. We may have incorporated specialized technology platforms, maximized individual productivity, or minimized integration conflicts through individual code ownership. The risk associated with too much specialization is apparent in many organizations with mainframe environments using COBOL and individuals developing on these systems who may be close to retirement. An individual contributor may be the only person who knows the code for 1 or more systems. If that person were to leave development on those systems would be crippled tremendously.One way to combat the risks associated with shared people is to setup an environment which supports learning and knowledge transfer. Some techniques that I have seen to be helpful are pair programming, mentor programs, and brown bag sessions. We cannot remove the need for shared people but as managers we can work to make the organization more resilient to specialization risks.

Context Switching

While working with some organizations I have come across many instances of excessive context switching by people across projects. One day I was presenting the use of StoryTestIQ as an acceptance testing tool to a group. During the presentation one of the group members asked how hard it would be for them to use this along with all of the other tools they were currently using on their other projects. My “spidey-senses” started tingling and I asked this person how many projects were they currently on? They answered “seven”. I asked how they could possibly deliver on the commitments of all those projects. There answer is that they haven’t been able to and it has been a real pain.

We can help people do a more effective job by minimizing the amount of context switching they are responsible to manage. This problem sometimes manifests itself with particular specialization but I have also seen this become a cultural norm in organizations. Some potential areas of improvement that can be made in the organization for context switching are enabling sharing of knowledge, restructuring from project focus to product focus for software delivery, and ask the teams associated with a heavily context switching person how they can alleviate this issue over time.

Removing Impediments

As a team starts to commit to an amount of work and deliver that amount of work at the end of each iteration, the team’s velocity begins to stabilize. Velocity is the amount of work the team can do from a particular Product Backlog that the whole team estimated over a specified iteration length. Jeff Sutherland, co-creator of the Scrum framework, once told me that “you cannot expect team acceleration without removing their impediments”. Acceleration in terms of velocity would be an increasing velocity over multiple iterations.

Management can help teams accelerate their velocity by removing barriers to team focus on software delivery. These impediments may be items such as missing hardware, unavailable people, and technology platform issues. As these impediments are removed the team’s focus on software delivery should increase thus accelerating their velocity.

Wrap Up for Tonight

I have mentioned a few organizational environment issues which could be improved and could help your team(s) become more productive. We can help real teams develop by keeping good teams together. If we start to minimize the amount of shared people across projects we can begin to alleviate risks associated with individual specialization within the organization. Working towards more focus for people in the organization who are currently context switching between multiple projects can increase their productivity and projects they are associated with. Also, management can help teams accelerate their velocity by removing impediments raised by the team. All of these I have found have been more fruitful than telling teams to work harder or more hours. Those alternatives usually just lead to software which is more costly to maintain and slowly decelerates the team’s productivity.

Additional material of interest on this topic:

Pete Deemer message to Scrumdevelopment mailing list on IT managers and Scrum:  http://groups.yahoo.com/group/scrumdevelopment/message/22323

Gerald M. Weinberg on Evidence that Teams are More Productive: http://secretsofconsulting.blogspot.com/2007/10/evidence-that-teams-are-more-productive.html 

1 Comment »

Wow! Again it was a wonderful day at the Amplify Your Effectiveness (AYE) conference in Phoenix, AZ. My only regret is that it is the last day of the conference. Here is what I gathered on the day:

Writing Workshop presented by Naomi Karten and Johanna Rothmann

I have been doing some writing lately and I this workshop was a great way to help improve my skills in writing. The first exercise that we did included gathering 4 random words from others and including those words in a 5 minute writing exercise. Here was my output from the words inspiration, care, limber, and diagram:It was an inspiration that Dwayne took tremendous care in developing such a limber diagram of Monty Python’s influence on American culture.

We then discussed some techniques and topics of interest such as:

• Personas - identifying your audience through pictures and names for the different audiences you are writing to
• Adjectives - use singing adjectives that truly inspire
• Adverbs - don’t use with some exceptions identified by participants such as fiction and when it “really” works (really and very are adverbs we should stay away from)

We did a second exercise which was 15 minutes of writing on any topic we are interested in. Here is my output from this:

Why does news only constitute bad news? Are shock and awe strands soldered into our DNA? I despise what current news portrays yet I am drawn to it on occasion.

One day I sat in my care with my ears fluttering in and out of public radio broadcasting. A broadcast caught my attention. A boy in his teenage years started a charity for building wells in Africa. I was immediately baffled. How could inspirational news seduce my passion?

After dodging and judging my own life’s charitable inadequacies I stood in a parking lot embroiled in an idea. Are we desensitized enough as a society to thirst for narratives of virtue? If so, what could I do about it?

Now, here’s where my story begins…

This workshop was lots of fun and I recommend it to anybody interested in writing.

Putting your Power to Work presented by Dale Emery

It was interesting to discuss “power” with such a great group of people.  Our first exercise was to define “power” by ourselves and then get into a group of 5 people and agree to a definition between us.  Here is what the team I worked on agreed to:

power - def. Potential to manifest change

I won’t be able to discuss each word and alternatives we went through in coming to this definition but I can tell you it was quite interesting to participate.  During the team part of this exercise we were asked to list examples of power that manifested in the exercise.  The activities which were identified as indications of power were fun to talk about and understand in terms of perspective.

We discussed the beauty of abstraction in values.  Here is an example from Dale:

An executive told me about one of the core values which was “fun”.  While going around the company we asked people what the company’s core value of “fun” meant to them.  They seemed to all have a different definition of “fun” and I asked the executive if that meant it had no meaning to the company.  He replied that this was the beauty of the abstract value “fun”.  Each person owns and crafts that value into something that is important to them.

I found this profound and a great way to discuss values including those in the Agile Manifesto.

Dale brought up another topic called the “Abilene Paradox” which is a book by Jerry Harvey.  Here is the story as I remember it:

A group of people were together at a house about 50 miles out of Abilene and were starting to get quiet.  One of the group members said to the rest of the group “why don’t we go to Abilene for something to do?”.  The rest of group looked at each other and decided to do it.  It was a very hot summer day and they had to travel 50 miles in a car with poor air circulation, go into Abilene and walk around in the heat, and then make their way back to the house.  When they got back to the house one of the group members said that they didn’t really want to go into Abilene.  That started a procession of other group members concurring with them and even the person who originally asked the group.  That person had just been posing a thing to do and if the group said yes they would be alright with it but didn’t necessarily want to do it.

We got into this story because one of the groups discussed how they came to agreement.  They said that each person looked around after a question about the definition being sufficient was asked.  Each person was nodding their head “yes” and so everybody assumed that all team members agreed.  This is not necessarily the case and many people recommend that you use a consensus technique such as the “fist of five”.

Overall this conference was incredible and walk away with some “relearnings” and new tools to use in order to be more effective in my work and life.  If you are interested there is going to be another AYE conference next year and all are welcome.  It is capped to a certain amount of people allowed to register for the conference and it is first come, first served.

No Comments »