Part 7: Best practices

In the previous blog posts in this series we discussed the role of technical leads (and in particular of Technical Product Owners [TPO]) in an agile software development process. Since then we have had several questions. The main question was: “I am in a classic architecture team. The development teams go agile. How can I get more involved with the teams?”. In this post I would like to focus on some best practices: how can you, as a TPO get more involved and facilitate the teams to deliver better quality? Read more

The metaphor technical debt was introduced at the OOPSLA conference in 1992 by Ward Cunningham. The phrase was:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…
The danger occurs when debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

The following picture shows how this “stand-still” described by Ward Cunningham is achieved.

http://theagileexecutive.com/2010/09/20/how-to-break-the-vicious-cycle-of-technical-debt/

In most discussions/blogs on the internet the following causes are mentioned and most are code related:

• the business forces the development team to take shortcuts, aiming to get the requested functionality life as soon as possible.
• the development team thought they didn’t need to design.
• the development team was incompetent/didn’t bother to write maintainable/changeable code.
• the development team  recognizes later for example by incorporating a change, that they made a suboptimal decision in the past (difficult to avoid).
  

Martin Fowler summarized this very well in his blog “TechnicalDebtQuadrant“. He distinguishes between reckless vs. rational behavior and  deliberate vs. carelessly/naively choices. But this is still mainly code related.

But if you look at the forms of technical debt in real life situations, you’ll see that these are not only code related. Technical debt may manifest itself in the following form to us:

• Code form (as mentioned already), e.g. duplication, high McCabe index, high unit-length per method, high number of parameters in methods, wrong comments, unclear naming of objects, methods, variables and properties, etc.
• Architectural form, e.g. violating separation of concern, the choice of not using a third party framework but build your own, not changing/adapting your architecture to the changes (gradual or abruptly) in the world around us.
• Testing form, e.g. a decision to not do automatic testing, while testing the system by hand is to complex or takes to much time, to conclude after testing that everything is OK.
• Deployment form, e.g. when a deployment is arranged in such a way that it costs a lot of time and is error prone, thus limiting the number of releases in a period in time.
• Documentation form, e.g. it is unknown how the system should react in certain situations because it is not functionally described. This makes future functional wishes time-consuming to fulfill.
• Functional form, e.g. by business requested and by the development team invented functionality that is not really needed and makes things unnecessary complex for the upcoming change.
• Project form, e.g. distribution of experienced people vs. not experienced people in your team, same applies to skills in the team, onsite/off-shore team distribution, etc.
• Organizational form, e.g. not asking your software (application) provider what kind of quality assurance policy they apply and if they can provide any quality figures based on a ISO maintainability-standard.

All these technical debt forms result in less changeability, more costs and delay in bringing new features life. All forms can be plotted on the TechnicalDebtQuadrant of Martin Fowler. Whether technical dept is categorized as deliberate, inadvertent, reckless or careful, it is good to be aware of this and see how you want to cope with it strategically.

Conclusion

Technical debt is not only technical and has several forms other then code form.  The metaphor “technical debt” is invented to visualize the problem of decreasing productivity in the life cycle of the software product. People  can communicate with the metaphor more easily about the problem it addresses. This way the concept became known by development community, and unfortunately less known in other areas listed above.

Management familiar with the metaphor, can use it as an advantage by making strategic decisions regarding technical debt, because they understand the concept of normal debt. But for strategic decisions the management should be aware how much technical debt there currently is (like a normal debt) and the chances of a technical credit crunch leading to possible technical bankruptcy….

So is technical debt only technical. No, it is not.

As explained in the previous blog, use-case slices are a great way of structuring your Product Backlog. This blog picks up where I previously left of by looking at a more concrete example. We will create the Product Backlog for a system for a library point-of-sales terminal.

 Read more

One of the major issues in organisations adopting Scrum (or most other Agile methods)  is the quality of the items on the Product Backlog. Product Owners are struggling with defining the User Stories needed to drive the process forward. And their role is often nearly impossible. How does one generate great User Stories that deliver real value, have just-enough detail, but also end up generating the documentation that is needed later in the application lifecycle?

The issue here is not whether User Stories are inherently bad (they are not), but that it is really hard to write User Stories in such a way that they really help and are useful in the long term. What we need is not a replacement for User Stories, but a better way to come up with them.

So, how should you go about arriving at great User Stories? That is what the remainder of this blog will look at.

 Read more

Some of you may know that I like to add drawings to support my posts.
This time the drawing itself is the subject of the post and you can actually use it. So please take a look at it and put it to use as you see fit. If you like it (or hate it…) or if you want to share your experiences using it please leave a comment.

You can download it here (PDF):
Xebia Scrum Process Overview

Or copy it from here

Lots of groups struggle with product features in the discovery phase of their products and services. Here is a relatively easy and quick exercise to make sense out of a mess of stories.
 Read more

At Xebia, we like experimenting with new solutions that enable us to give a more satisfying answer to our customers. One of these questions is: are Agile and Scrum applicable to non-IT environments? And though we are known with project such as wikispeed, we wanted to prove it on ourselves. So we did. Read more

Couple of weeks ago I realised something. As an Agile tester it’s really hard to communicate bugs! Testers are known for bringing bad news, but it is not easy to do it correctly. Specially when you’re in a Scrum Team and the heat is really on with bugs or issues flying all around.

 Read more

Are you a working mother? Do you feel a day simply does not have enough hours to get everything done? Do you wake up in the middle of the night, worrying about all the items on your endless to-do lists? Do you have to nag all the time to get your kids and husband to do anything at all around the house?

Well, then Scrum4Mom might just be what you need.  It is a totally new way to run your household. Scrum4Mom has the power to change your life.

Let me explain how it works.

 Read more

Scaling the productowner (PO) role is tricky business. When you scale up too much within the same context, things become cumbersome. We don’t want to bring back the same centralized fear ridden ineffective decision making climate, we tried to kill off in the first place. When people spend so much time and effort to bring back entrepreneurship, they don’t want to create layer over layer of hierarchical PO/CPO relationships.
So if there is this perceived risk of fallback involved, why do we actually want to scale the PO role at all?
 Read more