Book Review: Managing Software Debt

Recommendation: Must Have

I have recently read the book "Managing Software Debt" by Chris Sterling and must say I am quite impressed.  The author does a fantastic job explaining the subject and provides a lot of guidance on how to deal with the issue.  If you want to talk about ROI, this book is so packed with ideas and inspiration, it should cost thousands.  The author maintains an open mind throughout the book, and by reading this, you do too.

The author addresses software debt at many levels, more than I knew existed.  This book is part of the Agile Software Development Series, but I think this is a core book everyone involved in a software project should read (chickens and pigs).  I am surprised to see so few books on the topic, but this book is so well put together, I don't know if other books are needed.

Buy it, read it, follow it.

Cross Functional Teams vs Cross Functional Team Members

There is no doubt that having a cross functional team will increase your chances for success.  When the team is able to resolve their own issues and complete the work needed independent of external dependencies, the fault of delays fall onto that team.  Being cross functional empowers the team to better control their fate.  But that is where most organizations fall short.  Not only do you want to have cross functional teams, but you want to have cross functional team members.  Let me explain.

What does a Cross Functional Team look like?

A cross functional team has the necessary skills to deliver product features end-to-end.  In the example of a web application, it will involve people who have database, middle tier, and presentation tier skills.  If the application is graphic intensive, a graphic designer might be part of the team.  If the team as a whole, can cover the skills needed to deliver end-to-end features for 90% of the project, then the team is cross functional.

What about Subject Matter Experts (SMEs)?

The SME is someone who is an expert at a particular field or subject, where that skill is needed for the project, but does not quite need continuous involvement with the team on a daily basis.  Typically, these skills are around architecture, legal, marketing, and operations.  Depending on the app, you may want to staff your team to have one of these SMEs as part of the team.  Something to help you decide this is this question, “How often will the team go to this SME to complete a feature end-to-end?”  If you find yourself needing to go to this SME regularly and frequently, then consider making them part of the delivery team.

Okay, but what is the big deal about cross functional team members?

We have described cross functional teams, but cross functional team members is a different concept.  A cross functional team may be composed of a DBA, two developers, two testers, and a graphic designer.  For most end-to-end situations, the team would be able to implement potentially shippable features.  In practice, not all features will require such an even distribution of skills.  That is to say not all features will be 17% database work, 33% development, 33% testing, and 17% ui.

A cross functional team composed of cross functional team members may consist of 5 engineers.  Each engineer has skills in databases, development, testing, and ui design.  The strength of each discipline will vary among team members, but as a collective whole, they have the skills to get things done.  More importantly, everyone can contribute to each discipline.

This helps mitigate risk when in one iteration, you have unbalanced work.  At the beginning of a project, there may be more database work needed than ui.  In the middle of a project, you might need significant database work because a design flaw was discovered and some refactoring needs to be done.  If you only have a cross functional team, then your DBA will be overloaded.  If you have cross functional team members, those members can help contribute to the database workload.  This approach also supports Kanban development methodology.

Divide, Conquer, Swarm

In action, this is how cross functional team members would operate.

Divide.  The team would strategically divide up the work that needs to be done for a feature such that it would play off their strengths.  Having people do areas of work where they are strong will produce faster results.  You also want to make sure you create opportunity for cross training (paired development).  Pairing with the strong-skilled team members will help elevate the skill on the team.

Conquer.  With the work divided, the team would attack the pieces with full force.  But it is not just all about getting your piece of work done.  Along the way, talk a lot with others and integrate as much as possible.  Get those data access calls hitting the database.  Wire up the UI with the presentation and business logic.  At a minimum set up the interfaces so the feature is making calls all the way through the call stack, even if the logic in the middle isn’t there yet.

Swarm.  As one group (pair) completes their work, they will move on to help their other team members get their work done.  If the database work is done, help out the data access group.  Maybe they need help with unit tests, or implementation.  Perhaps coordinating with the tester on the use cases that need to be supported.  The goal is to swarm the other team members with overwhelming support and assistance.  This will also foster a strong team motto of “We’re all in this together”.  You will have bottle necks, but this swarm technique will help eliminate the bottleneck.  This is only possible if you encourage cross functional team members on an already existing cross functional team.

If you staff your teams as 3 developers and 3 testers, where the testers are not allowed to write application code, you’re setting yourself up to have bottlenecks.  If developers can’t help write tests…bottleneck.  If your DBA goes on vacation…BOTTLENECK.

Requirements Are Dangerous

Here are some problems with requirements:

• Requirements are incomplete
• Requirements are wrong
• Requirements include features that don't make sense or will likely not be used

The problem with giving the requirements to engineers are:

• Engineers think the requirements are complete
• Engineers think the requirements are correct
• Engineers think this feature is worth implementing
• Engineers take the requirements too literally

This gets very expensive very fast.  Some recommendations to fix this problem:

• Talk to the person who provided the requirements.
• Review the requirements in person and in real time (not via email or by passing a doc back and forth)
• Question the value of the feature
• Demo the product as it is being developed to make sure you are on the right path.

For those of you who will take this article literally and argue the definition of "requirements", you probably take the requirements too literally too and have been falling into the same problem for years.

Quote: Age and Wisdom

I am wrong more often than not.  Age has just taught me to say nothing until I am sure I am right.

-- John J.

It's About the Product, Not Velocity

Watch out when the team or management are too concerned about velocity.  The problem with metrics, is that people will start trying to game the system to increase the numbers they think that you think are important. Imagine this conversation:

Good day Boss.  Good news, the team has increased their velocity by 125% in the past 4 sprints.

Some bosses would be happy with this, but out of context, this is an inconclusive statement.  That could have been 4 sprints making pixel level adjustments to the UI, or perhaps updating the CSS to use a different shade of green.  What about the product?  What value is being added to the product?

Look at the product and your cost.  Figure out your burn rate for the team per sprint.  Let's say it costs about $10K to run the team for a sprint.  Instead of the quoted scenario above, consider this scenario:

Hi there Boss.  We just spent $10K over the past sprint and this is what changed in the product.  Are you happy with what you just paid for?

Please, make a good product at a good cost.

Quote: Simple Definition of Business

"A business is a collection of rules that manage a bunch of lists."
Camron Shimy

Trash and Interfaces: Working Together

I took out the trash this morning (please hold your applause).  I wheeled out two trash cans, a green one for yard trimmings, and a black one for other household trash.  This was a very easy task to accomplish where at the end of the day, my trash cans will be empty and I will be able to fill them back up again.  Ah...closure.  How does this work?

Here are some things that help make this work:

• The point of interaction between me and the garbage company is the street curb.
• We have a defined transport container.  Rather than throw all this junk on the street, there is are nice, color-coded containers that indicate to me what to put into each container, but also lets the trash company truck drivers know which containers to pick up and which to leave for other trucks.
  
• We have a defined time frame
• The trash is collected between 6am and 6pm.
• I can control the quality (more of a boolean, but sometimes not)  If I want to maximize my chances of the trash being picked up properly, I need to put it out before 6am.  I also need to make sure it all fits in the containers provided by the trash company.  I can always skip a week if I please.
  
• We have a defined frequency, once a week.
  
• We have very clear responsibilities
• I put the cans out
• They empty them
• ...and some other minor things that I don't feel like typing.

Wow, that is a lot of coordination.  Here are some points that make this easy

• My neighbors have the same service and do the same thing, so it is easy to share information about scheduling, overflow, and who to call if there is a problem.
• This is a standard and repeatable process
• When the schedule changes (a holiday here and there), I am notified of the new schedule
• This process is similar to other trash companies in the area, so some kind of "regional industry standard" exists. 
• I don't care who picks up the trash, as long as someone does.
• They don't care who wheels it out, as long as someone does.

Why don't you develop your software the same way? 

• Agree to the same (and clear) goal
• Work as a team
  
• Accept changes
• Define responsibilites
• Make it easy to use
• Provide value
• Keep it simple
• Interact frequently
• Care about what needs to be cared about

Please tell all your friends about this mind blowing article.

How to Update a Changeset for TFS

There are many reasons why you may need to update a changeset in TFS. If you need to update the comment, please read the post How to Update the comment after check in.

In my environment, I had to do more than this. I have a check-in policy where all changesets must be associated with work items. If the policy is not met, a policy failure can be seen in the changeset reading

You must associate this check-in with one ore more work items. 

This policy can be overridden, but even if you override it, and your changeset is committed, how do you associate a work item with that changeset?

Here is how.

1. Find the changeset number. You can do this by viewing the history for your project.
2. Now open a work item that you want to associate with the changeset. 
3. The work item template should have a "Links" tab. On that tab, "Add" a link.
4. Set the "Link type" to "Changeset". 
5. In the "Link details" section, set the "Changeset:" value to the changeset number you looked up a few moments ago. You can also "Browse" for it if you don't like the "History" approach I mentioned above.
6. Add a meaningful (or meaningless) comment.
7. Click "OK" 

Now, the changeset doesn't have any policy failures (or at least not related to work items).

Scrum: Accomplished vs. Did, Hidden Impediments?

Think about what you did yesterday and what you are going to do today. You can probably make a list of things. Take a shower, eat lunch, go to some meetings, work on this project, refactor some code, etc.

accomplish 1: to bring about (a result) by effort

Now think about what you accomplished yesterday, or what you are going to accomplish today. You will likely have a different list. Finished reading a book or chapter, got requirements from our customer, verified a bug, etc.

do 3a: perform , execute

In your daily stand-up meetings, be aware of people talking about what they did or are going to do instead of talking about what they accomplished. Regardless of your position on the team (Product Owner, ScrumMaster, Delivery Team member), everyone should hold everyone accountable for talking about accomplishments.

If you have a lot of things to do, where those things don't contribute to your sprint backlog, those things might really be impediments.

Today, I am going to work on the code for the new login system and go to a sales meeting.

Whoa! I hope the ScrumMaster catches this. Is this sales meeting a critical part of the product? Will it interfere with the team's ability to deliver? Is it a 10 minute chat or a 3 hour presentation on something not related to the project? How frequent are these meetings? Was this planned? Perhaps this is a meeting where the employee's manager can excuse the worker from, so the worker can focus on the sprint.

Let's re-do that part of the stand-up in a few different ways.

Today, I am going to start coding the new login system. I have a sales meeting as a blocker. It is going to take half the day.

Today, I am going to start coding the new login system. I have a sales meeting to listen to some feedback from our users.

Hopefully, this illustrates how a different mindset can improve the value of the daily stand-up.

Is Barack Obama the "Scrum President"?

The first moment I thought President Elect Barack Obama might be the first "Scrum President" was while I was watching Obama's Inner Circle Shares Inside Story on 60 Minutes.  David Plouffe, Obama's campaign manager, mentioned how his team only planned for days instead of years.  They were "more agile" and "not afraid to take risks". Now, just because someone says "agile" doesn't mean they follow scrum, but I haven't heard many politicians talk like this group does.

There are a few quotes from another story, Obama On Economic Crisis, Transition, that have elements of "inspect and adapt"

[It] is not always getting it right, but projecting a sense of confidence, and a willingness to try things. And experiment in order to get people working again.

If something doesn’t work that they’re gonna try something else until they find something that does.’

If the idea is right for the times then we’re gonna apply it. And things that don’t work we’re gonna get rid of.

Regarding transparency, Obama said this:

I think that we have to restore a sense of trust, transparency, openness in our financial system.

Scrum is also very big on the concept of "team".  During the week of Thanksgiving (which I don't have a direct reference to, but heard on KNX 1070 radio), Obama said in that America will succeed or fail as one people.

I know I am drawing conclusions on some very loose quotes, and I doubt anyone in Obama's campaign ever said, "Hey, let's run a scrum campaign," but I am seeing enough of an agile spirit, which is the most important thing. 

Scrum and Agile have worked very well for me in software engineering, and I hope it works out well for politics and government too.

Setting Expectations, Getting Results

When people fail to meet expectations, it is often because they didn't know what expectations to meet.  Being a ScrumMaster, team lead, and manager, the most effective way I clear this up is to explicitly tell teams what I expect.  This phrase, although quite obvious and trivial, helps me achieve that goal:

"I expect you to ..."

Yes, it is that simple.  By clearly letting your team (or boss, spouse, friends, etc.) know what you are expecting, they are better equipped with the right information to meet your expectations.  Here is a specific example:

Self-Organizing and Self-Managing Teams
When teaching scrum to a team, I tell them that "Scrum teams are self-organizing and self-managing".  Now that the team has been told, don't expect them to start being self-organizing and self-managing.  Aside from the culture and personality changes that need to occur to make this happen, it is much more effective to additional tell the teams, or individuals on the team, what is expected of them.  I follow-up with this by telling teams and individuals, "I expect you to be self-organizing and self-managing."  This may seem repetitive, but it is very effective.

Here are a few more examples of expectations:

• I expect you to get to meetings on time, not 30 seconds late.
• I expect you to meet  your commitments.
• I expect you to help others with their tasks as though the tasks were yours.
• I expect you to be pro-active, don't wait to be told what to do all the time.

AT&T Uverse Installation: Failed

I was very disappointed yesterday by not being able to get AT&T Uverse.  After waiting about one year for the service to be available in my area, I found out that it is still not available in my area.

There is some sort of junction box on the street that is maintained by AT&T.  You have to live within 4,500 feet to get the service.  I live 6,700 feet, and can't get the service.  The signal is too weak for the service to work.

The technician showed up at 2:00, at the end of the two-hour window quoted.  He spent about an hour trying to get the signal, but was not able to.  He told me about the situation and opened a Help Ticket to see what could be done.  At around 6:15, he told me I cannot get the service because I live too far from the junction box.

Hopefully, AT&T will add a box closer to my house so I can get the service.

AT&T Uverse: Order Placed

I placed an order to get AT&T Uverse today. The phone call took 30 minutes and the customer service rep was very nice. I got the U200 plan with 3.0 Mbps Internet. It looks like a good deal. Here is the breakdown:

• U200 $59
• HD "Technology" fee $10
• 3.0 Mbps Internet $30
• Extra TV Receiver $5
• Monthly Total: $104
  

They are running a promotion so I get $14 off per month for the next 12 months, which brings my monthly total to $90. I am also eligible for the $200 cash-back. If I amortize this over 12 months, my monthly total drops $16.67 to $73.33.

I also was able to bundle my local and long distance service which was $41 before taxes, but is now $32.25.

I am currently a Time Warner customer, but will not be for very long if this all works out. After taxes and fees, I am paying $108 for Time Warner. Compared to the $73.33 for the next 12 months, it is worth trying.

Even after the 12-month promotion, the features, channels, and better equipment will be worth the extra few buck over Time Warner. I have been quite frustrated with the lack of HD selection with Time Warner.

Also, there is no contract, installation fees, set-up fees, or anything like that, or at least none that I agreed to. Not having a contract or equipment to buy is a big feature for me, which is why I haven't gone with DirecTv or DishNetwork, although I have heard good things about them.

Soft Skills: Anything Else vs. What Else

As a Scrum master, I make a conscious effort to allow the team to be creative and voice their ideas, however, sometime I need to control the pace in time-boxed activities. 

A common activity is asking the team to list items which I write on a whiteboard.  Sometimes teams can be a little distracted, tired, bored, or unsure of what should be on the list.  Sometimes teams are very engaged, passionate, and focussed.  In either case, there are two questions I ask, which I learned from Chris Sterling, which helps me control the pace.

"Anything else?"
I ask this question when we need to move on to another part of  the activity or conversation.  This is most commonly used, but is easy to say "no".  Here is an example exchange:

I am going to the market to get milk.  Do we need anything else?

No, that is it.  thanks.

"What else?"
I ask this question when I think there are more items to put in the list. It is easy to say "no" to "anything else", but when asking "what else", there is more of a compelling reason to give an answer. 

I am going to the market to get milk.  What else do we need?

Hmmm...we need eggs too.

With either approach, if there are or are not any items left for the list, the team has a way out, but one way is easier than the other.

Make it Visible, Make it Big: Sprint Burndown

An important tenant of Scrum is transparency.  Keeping the teams metrics and state of the project visible to others not only enables others to make decision based on this information, but it also has a great psycological effect on the Team.

Where is your team's sprint burndown chart?
A good place to put the sprint burndown chart is in an are where it gets a lot of visibility, but also where important people see it.  The burndown chart can be placed in a Starbucks, but the Starbucks clientèle is not interested in this.  I have placed the burndown chart on the Director of Engineering's office door, or on the door of the Product Owner.  Another effective place to put the chart is in a room or hallway where the peers of the delivery team can see it.  Of course, you want the delivery team to see the chart all the time too.

Make it BIG
People tend to respond to things larger in scale, than small things.  For example, the worlds largest thermometer gets a lot of attention just because it is big.  Nothing special about saying it is 86 degrees, but if you say it in a big way, now you have some attention.

Printing the chart on 8.5" x 11" paper isn't going to cut it.  Draw a chart on a large easel pad (24" x 37") or if you have a HP Designjet T610 with a 44" spool of paper, now that will work.  Add some colors and make the chart easy to read.

Scrum Tools: Points in eScrum and TFS in Visual Studio

I have been using the eScrum project template in Microsoft Visual Studio TFS edition for a few sprints now.  Along the way, the team noticed some issues with the template.  In TFS, by navigating to Team > Process Editor > Work Item Types > Open WIT from Server, I opened the eScrum Product Backlog Item template and made some changes.

Points
The Product Backlog Item template is missing a "points" field to indicate the relative size of a PBI.  There is a Baseline Work field, but that is used to represent the number of hours for the PBI in reports. I decided to add a Points field where a dropdown shows Fibonacci based numbers (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, 250, 500, ?, infinity).  Since there are values such as "?" and "infinity, the field type must be 'String'.  I could have used the Baseline Work field, but that allows people to enter values that could complicate things, such as entering 21 instead of 20.  To avoid the debate, or having to correct this, I added an ALLOWEDVALUES rule to control this.

Query
Now I can create a query to allow me to see what items does the team need to estimate.  By using the team's velocity, this query can include items that are larger than half a sprint, which indicates the team needs to work with the Product Owner to break this down into smaller PBIs.

Quote: Communication

"Can I talk to the guy who is telling you what to tell me?"
Dan C.

Google AdSense Login Troubles

I was having trouble with my AdSense account. The account was inactive for a while, but then I decided to revive it. After searching on Google Groups and other web pages I was unable to find a solution that worked for me so I emailed their support team, which responded in one day. I hope this helps someone else out.

Symptoms:

When I login to AdSense, I get the message "An AdSense account does not exist for this login, as you have not yet completed an application."

When I try to sign-up, I get the message "A user with the email you specified already exists, Please select a different Google Account login to access this account."

Solution:

1. Please make sure that your AdSense account password is different from
your Google Account password.

2. You can reset it at https://www.google.com/adsense/assistlogin?hl=en_US

3. Once your passwords are different, you will need to log in to AdSense
with the AdSense email and password .

4. Once you log in to your AdSense account, please migrate using
https://www.google.com/adsense/migrate-login-1

Certified Scrum Product Owner

In July of 2008, I continued my Scrum education by taking a two-day certification course in San Jose. It was taught by two fantastic trainers: Chris Sterling and Bryan Stallings. I highly recommend this course for any product owner, project manager, program manager, product manager, ScrumMaster, etc., if you are using Scrum or not.

Certified ScrumMaster

In June of 2008, I went to UCLA for a two-day training course to get a ScrumMaster certification. The class was taught by Chris Sterling from SolutionsIQ. I went back to work and started applying what I learned immediately.

The challenge was, I was trained to use Scrum, but others weren't. It was as though only one player knew the rules of the game. So how can I fix this...workshops. By holding a few workshops (or crash course), I was able to get the team up to speed...kind of. I couldn't fit all two days of exercises and material into a four-hour meeting.

After one sprint (two weeks), the team had felt what it is like to sprint. It sure was fast and felt short.

So now the team knows (or was at least informed) of the rules, guidelines, and goals of Scrum, the next challenge is to get them to play as a team. They are in the forming stage of the Tuckman model, and over time, will hopefully get to the performing stage.

By continuous inspection and adaptation, I am looking forward to watching the team evolve and improve over the next few sprints.