This week, an interview from SearchSoftwareQuality.com with me came out on the book Managing Software Debt: Building for Inevitable Change. The interview has 2 parts. The first is a discussion of software debt and the second focuses on addressing software debt. Here are links to the interview:
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
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
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.
We are truly excited that AgileEVM has been chosen as 1 of the top 12 finalists for the First Look Forum, an event put on by Northwest Entrepreneur Network (NWEN). The entire process has been an amazing and informative experience thus far. We have received coaching from some of the best in the NWEN community on our business plan, executive summary, product pitch, and much more already. If you are part of a startup that does not already have funding and want to learn how to hone your business, we definitely recommend being part of the next NWEN First Look Forum.
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:
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
Matt Heusser, on behalf of InformIT, conducted an interview with me regarding the book Managing Software Debt: Building for Inevitable Change. We discuss what software debt is, some ways that it can be managed, maintaining a single list of work, how software debt is measured, and we even got into training and our product AgileEVM.com. You can read the interview at http://www.informit.com/articles/article.aspx?p=1684785.
For several years now, I have been using less and less sticky notes. This is because I use something much better: Drafting Dots. They work better, last longer, cost less, do not harm any surfaces, and make my life much easier.
Now, I can easily use mail merge or tables to print out stories using four cards per page. I use card stock (120# in US) and often use colored paper to color the product backlog. Any printer, a paper cutter and I am quickly ready with a stack of cards that work like index cards or sticky notes for emergent conversation and valuable collaboration. We can lay things out on tables and then put things on walls which, is something sticky notes cannot do well.
I am always ready with index cards and drafting dots. They are cheaper and easier to use in many flexible ways. I have seen drafting dots hold up cards for a month and then get moved without issue. Try them out, you may find yourself using far fewer sticky notes.
Kelly Waters is now providing a great service to the Agile community by integrating content from talented writers and thinkers at All About Agile. If you are interested in furthering your knowledge about tools, practices, process, and people in adopting Agile values and methods this could be a great spot for you. Thank you, Kelly.
This presentation focused on two themes: asserting quality - an opportunity agile presents - and leveraging adaptive planning, which is a consequence of agile software development. AgileEVM became a big part of this talk when the audience requested more information about it at dinner.
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 [[http://bit.ly/hrLemn]]. 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 [[http://bit.ly/aufy23]].
We need a definition to continue. In this session we settled on
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:
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”).
Then we asked:
The majority of everyone who answers these questions would prefer to have a job like the one described on the “Fine in Agile” chart.
One of the many benefits of Scrum is early identification of roadblocks that could stop a Team from meeting their goals and commitments. At the Daily Scrum meeting, team members typically answer 3 questions:
Many teams start with these 3 questions but then have difficulty not making this meeting into a status meeting for managers. The real focus of this meeting is to identify issues that could impede the Team’s current Sprint delivery commitment. We create burndown and other visible charts and tools to help us spot impediments early so we can respond more effectively.
In our Scrum courses, we make sure that Teams, and especially the ScrumMasters, know how to manage impediments for a Team. There are three main categories of impediments, each managed a little differently.
It is important to adopt a communication plan that addresses how impediments will be managed and escalated in a scaled Scrum environment. In our consulting with organizations that have scaled Scrum teams, we’ve learned just how important effective impediment management at the individual, team, organization, and executive levels can be. When not handled well, the risk of not meeting date and budget commitments increases significantly.
Screen capture of "Add an Impediment" popup dialog on AgileEVM.com.
Given the importance of impediment management on dollars and dates associated with a release, we’ve enhanced AgileEVM to manage impediments at the release, project, product, program, and project portfolio levels. There are 6 attributes to an impediment that we have found useful to manage them effectively:
When impediments are entered into AgileEVM, they are made visible on the “Im
pediments” tab for every level of the project portfolio.
Remember that using Agile methods such as Scrum do not solve your problems but they do make identifying them early much easier. Only through good communication channels and action do true improvements result from using Agile methods.
How do you manage your impediments at different levels of the organization? We’re always glad to read your comments.