, , , ,

What is technical debt?

Our team is about to go live in few days and we are still discovering loads new issues. Of course frustration is mounting and its getting harder and harder to explain the extra work team needs to do. When someone in the team suggested to go back to the drawing board, my heart sank into my stomach. I did some research, and came across Martin Fowler’s articles man-carrying-donkeyabout technical debt and it felt like deja vu moment. So what exactly a technical debt( or code/design debt) is? The picture on the left describe it very well.

It is:

  1. An unsustainable design that is chosen as a shortcut to make a release. Where the release offers sufficient value to the customer, a PO might accept (or even request) such a shortcut.
  2. Messy or badly written code

The former is a deliberate and prudent decision. The team is aware what is happening and that the design shortcut has to be rectified in the following spring.

The latter is either reckless or inadvertent. The programmers might not be mature enough to know that they are injuring debt (that their code design is not sustainable); we call this inadvertent debt. Or the programmer might not care; then we call this reckless.

Finally, we might only know that we incurred debt after the fact, i.e. we only find out later that our design is not sustainable.

In general, technical debt is a metaphor to explain to POs or stakeholders that there are issues in the code base that have to be addressed in order to keep the code sustainable. Unpaid technical debt means that whenever we want to make changes to the code, we have a bigger effort, because we have to work around the debt. So using the metaphor, we are paying interest and like with interest on a credit card, this can grow to the extent that all our time is used to pay down interest.

Like with a credit card, if we keep using it without paying back the debt, we lose at some point the ability to incur new debt, i.e. we lose an option to cope with exceptional circumstances. It is therefore sensible that technical debt is paid down as quickly as possible.

What do we do in a situation where such debt has become crippling? In an environment I worked in as a coach with an aggressive delivery deadline, the defects were so massive that team was almost unable to make any progress on customer value. There was no way all defects could be cleaned while adding features at the same time. So there was a threat of having a poor quality product by the time the project went live, something the PO and the stakeholders were unlikely to allow. The project was in risk of failure.
To address the defects, it was agreed that the team would do short sprints(1-2 days) until the debt was under control.

A backlog of defects was created and shared with the PO and Stakeholders. Every morning the progress from the previous day was reviewed and the process itself was examined in a small retrospective. Then the work for the day was prioritised and the team would make the agreed improvements.

So every day, a full scrum cycle was carried out. This brought the development back under control and the quality back where it needed to be. In the end, the project was allowed to go live.

In another case with delivery pressures, under inspection it become clear that for a release, it wasn’t necessary to actually deliver a fully functioning version. What the PO was really after was being able to show how the final system would look and behave like to users. The team was able to ignore some inter-system dependencies in the planned release and the PO agree that team would be given time in the following release to resolve these issues.

In this scenario, the debt was treated like features. In cases where work has to be done that is only indirectly related to value the customer can perceive, technical debt can be treated like a story with its own card and estimate. Where debt is an ongoing issue, the team can ask to have a fixed amount of time in each sprint to address debt. This is not uncommon in Scrum teams working on legacy systems.
Learning:

• Technical debt can come in various forms, deliberate or unknowingly. We can be aware we have debt or we might not know.

• Technical debt taxes progress and if not resolved can cripple a project.

• We should pay down debt as quickly as possible.

• Debt can handled like stories and be subject to prioritisation.

• It is good to discuss debt – where we’re aware of it – with POs and Stakeholders so they help prioritise how we pay it down and are aware of its existence.

I suggest team should plan code refactoring as part of sprint backlog. This will keep them on top of technical debts and make code design clean and sustainable.

Happy coding and stay agile.

AgileKrish

Reference:

  1. http://c2.com/cgi/wiki?TechnicalDebt
  2. http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
  3. http://www.martinfowler.com/bliki/TechnicalDebt.html
, ,

Test and Behaviour Driven Development

Someone from my client’s team asked me the difference between TDD and BDD yesterday so I thought it would be a good idea to research and summarise it in simple words. According to Agile Alliances

Test Driven Development is a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring).

It can be succinctly described by the following set of rules:
1. write a “single” unit test describing an aspect of the program
2. run the test, which should fail because the program lacks that feature
3. write “just enough” code, the simplest possible, to make the test pass
4. “refactor” the code until it conforms to the simplicity criteria
5. repeat, “accumulating” unit tests over time

and

Behaviour Driven Development is a synthesis and refinement of practices stemming from TDD (Test Driven Development) and ATDD (Acceptance Test Driven Development).

BDD augments TDD and ATDD with the following tactics:
1. apply the “Five Why’s” principle to each proposed User Story, so that its purpose is clearly related to business outcomes
2. thinking “from the outside in”, in other words implement only those behaviors which contribute most directly to these business outcomes, so as to minimize waste
3. describe behaviors in a single notation which is directly accessible to domain experts, testers and developers, so as to improve communication
4. apply these techniques all the way down to the lowest levels of abstraction of the software, paying particular attention to the distribution of behavior, so that evolution remains cheap

Thanks to my friend Liz for translating test driven development to behaviour driven development.

[ws_table id=”9″]

I think this is one of the most powerful tools Business Analysts can put in their tool belt. Why don’t look at our user story writing workshop using BDD.

, , , ,

Agile Tasking

Customer: I want to build a home. Could you give me an estimate?

Builder: No I cannot! You need to give me more information like how many rooms, plot size, how many floors etc.

Customer: I need you to build me a four bedrooms, two and one-half baths, a gourmet kitchen, walkout basement with media room and three-car garage in Pennsylvania.

Builder: Now you are talking! Do you insist on top-of-the-line cabinets and appliances for your gourmet kitchen, or will mid-range ones do? Are you planning to side the house with cheap vinyl or expensive stone brick? Is the house going to be one story, or two?  Will you have simple, rectangular rooms that minimize the materials and the labor required for framing, or unusual shapes like octagons with vaulted ceilings? What sort of flooring, bathroom fixtures and heating and cooling system will you have? Is the lot easy to access, relatively flat and easy to dig, or is it rocky, heavily wooded and uneven?

Similar to above story , its very difficult to provide an estimate when your customer asks the scrum team how long will it take deliver this feature or functionality. Breaking down the user story into tasks will help team to estimate their work accurately and track sprint progress.

What?

Tasking is the process that the developers undertake to understand, design, and properly prepare to write code for a user story.

Why?

The challenging decisions are made during tasking.  If tasking is done properly then the actual coding is a much simpler task.  I believe that this is the most important thing any scrum team does.

Who?

It’s important that all developers and testers attend.  This serves multiple purposes.

  1. every developer on the team begins to become comfortable with the code base for all of their applications
  2. every developer has the ability to include their input on the design and solution
  3. any developer on the team should be able to pick up any story at any point to complete the tasks because they were there and the expectation should be such.
  4. every tester in the team can ensure they’re aware of the solution and that it meets all of their criteria.

It’s also good to have the BA there to review the story with the team and answer any questions.  Once the story is reviewed it usually makes sense for the BA to go about their day and to let the developers get into the technical details.

When?

Second half of the sprint planning session or right before the work is to be done (if  other stories being implemented that may change the approach and invalidate the tasking that was completed).

How?

Step 1: Review Current Code

The developers will review the current code that relates to the user story.  They will walk through the code to ensure that everyone is on the same page with what the code currently looks like.

Step 2: Decide on Changes to Code

The developers will discuss how to modify the existing code to make the addition of the new functionality simple.  It’s common for developers to perpetuate the logic found in the current code (good or bad), so always considering ways to change the code is a key to having well written code.

Step 3: Draw a Sequence Diagram

The sequence diagram is a visual representation of the classes that call each other to accomplish some discussed part of the code.  If this diagram is complicated, then it’s a great indication that the code should be modified so that the diagram is less complicated.

Step 4: Task Out New Work

Once everything is decided, the actual coding tasks should be created and ordered.  Each task should take under an hour to complete.  The developers can then grab these tasks and complete the story in small chucks in separate streams ( if needed).

Why Tasking Doesn’t Happen?

For all of the reasons stated above, it’s important that the teams task stories.  It’s easy for developers to take shortcuts and skip tasking.  One of the main reasons is a lack of collaborative areas.

Tasking can take developers 4+ hours, and they need a whiteboard, projector and computer to properly task.  Finding a room like that for 4+ hours is challenging at times.

 

, , , , ,

Difference between Product backlog Grooming, Sprint Planning and Elaboration

Difference between product backlog grooming, sprint planning and elaboration

Cancelled sprint planning meetings, frustrated team because there are not enough stories in the sprint, too many stories to deliver (feast or famine situation) are symptoms of poor planning and lack of discipline.  I usually take the following  3 steps to ensure smooth flow of user stories and high productivity.

Step 1: Pre Planning

Step 2: Sprint Planning

Step 3: Elaboration

Recent debate over value of these activities prompted me write this blog. To make things clear, I would explain each activity in detail:

Pre Planning (Backlog Grooming)

Who: Product Owner and team representatives

When: Mid sprint

What: Backlog grooming (also called maintenance or pre planning) is not a formal ceremony of the Scrum process, but it is advised that PO, BA and team representatives to dedicate 10-15% of every sprint to this activity. During pre planning, everyone helps prepare the scrum backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort( t-shirt sizing) for existing stories. PO identifies candidate user stories (based on priority) for next sprint planning and team representative helps PO to alter list based on technical feasibility.

Why: Groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the appropriate team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning always occurs prior to the sprint planning meeting.

Sprint Planning

When: In Scrum, every iteration begins with the sprint planning meeting.

Who: Product Owner and the team

What: At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to two to four hours, this meeting is a conversation between the Product Owner and the team. During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. PO to answer questions, clarify acceptance criteria, or renegotiate. Team sizes story in story points based on complexity and effort required. Stories are broken down to tasks and tasks are estimated jointly in hours. Estimation must be done as group as it varies from one team member to another according to individual’s experience. Scrum method encourages collaboration and reduces the risk of underestimating or over estimating any task.

There are two defined artifacts that result from a sprint planning meeting:

  1. A sprint goal
  2. A sprint backlog

Why: Helps Product Owner to decide which stories are of the highest priority to the release and which will generate the highest business value, but the team has the power to push back and voice concerns or impediments. This is a good thing since the team may be aware of a legitimate impediment keeping the team from moving forward. This helps team to work out their capacity, plan stories according to capacity and commit to a realistic target. Setting unrealistic target and not achieving it sends a negative signal to stakeholders and affects team morale.

Warning !!: Some teams may under commit and over deliver.

Elaboration:

Who: PO, developer and tester

When: Each of these “levels” of requirements are addressed progressively at various points in the sprint. Usually before starting a user story. The product owner should be available for consultation if the development team needs further clarification on requirements throughout the day.

What: In order to actually develop a user story you need to consider several levels: Themes or Epics; Features; Stories; and then the nitty-gritty details associated with Stories. Progressive elaboration of user stories just means that big user stories are broken down into smaller ones and filled up with more detail when they appear closer to implementation

Why: Whenever the development team tackles a new user story, elaboration ensures that any unanswered questions about it are answered so that development can proceed. The product owner works with the development team to elaborate user stories, but the development team should have the final say on design decisions.

Hope this explains why we have various ceremonies and what value they add to the successful delivery of sprint objectives.

Keeping agile simple, pure and meaningful.

, , , ,

Estimating story from trenches

In today’s user story writing workshop my client asked me how do you estimate a user story?

To me, Complexity, Effort and Time are three key things we need to consider while estimating any user story. You look at the complexity of a story to derive the effort required to estimate the time it will take you to finish the story.

To use an analogy of carrying a log of wood from point A to point B:

COMPLEXITY: “How BIG and HEAVY is the Log of wood?”

EFFORT: “How much horsepower is required to pull this log?” This is where Story point comes in.

TIME: Say it takes 2 Horsepower, “how quickly can 6 horses move the log from A to B?” And this, we all know is velocity which can only be derived after a few Sprints.

Complexity cannot be seen in isolation and effort cannot be measured without knowing the complexity.

P.S. I can assure my readers that no animals were harmed in the making of this blog.