Posts

, , ,

Scrum team failing consistently?

We love firefighters! Don’t we? They are Heroes! But not in software development. In any Scrum software development, very few teams actually manage to find the time to refine and properly compose their stories (user requirements). Because of this, they’re constantly taking time to try and analyse the software requirements during the projects sprints.

This inevitably results in stories being rushed, ill defined, slapdash and careless. This delays the development of the software and  testing, which  should be a major activities, is compressed and squashed into just the last one or two days of the sprint.

And the result?scrum

Firfighting !!!!

The result, is of course, defect in the code. The team then starts firefighting, to try and fix the problems that were born of their ill planning. However, because they’re so caught up in their self-imposed firefighting, they don’t have time to analyse and create competent stories for the next sprint, so they dive right back into the vicious cycle of firefighting.

, , , ,

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
, , , ,

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.

, ,

New to Agile?

In short, agile and lean are general concepts, the former basing on Agile Manifesto and the latter on Toyota Production System. Then we have Scrum or XP, built over agile, and Kanban, built over lean, which are specific methods teams can implement, like Prince2.

Personally, I don’t treat agile and lean movements in a very orthodox way — they base on the same principles. So, to some point, they’re overlapping. Also, you will find teams mixing methods from both houses, Scrumban (a combination of Scrum and Kanban) being probably the most common.

If you wanted to position agile/lean methods somehow I’d say that:

  • Scrum is the closest to the old-school project management methods, although it doesn’t really deal with formal side of project management.
  • XP focuses on engineering practices and is generally programmer-centered.
  • Kanban is often dubbed change management framework as it doesn’t change the way team works on the day 1 and lets the process evolve over time.
  • As all three focuses on different things, it isn’t uncommon to see them, or their parts, used jointly.

If you want to learn more I’d start with such set of materials:

  • Introduction to Scrum on Mike Cohn’s site. If you want more on Scrum Mike Cohn’s site is a good place to find also more advanced stuff on Scrum.
  • Once you know what Scrum is I’d strongly recommend Henrik Kniberg’s and Mattias Skarin’s minibook Kanban and Scrum – Making most of both which is great in terms of describing Kanban but has a lot of referrals to Scrum.
  • For more advanced stuff on Kanban I’d recommend Limited WIP Society articles (topic for my next blog).
  • Good kick start on XP can be found on Ron Jeffries’ site.

In terms of books as a kick start, I’d recommend:

  • Mike Cohn’s Succeeding with Agile for Scrum
  • Kent Beck’s Extreme Programming Explained for XP
  • David Anderson’s Kanban for Kanban

If it is too much of a hassle to read these books and digest then contact us and we may be able to help you.

, , ,

Agile Learning and Seeking Knowledge

India’s Mars Mission

2013-11-05 09.23.07

A proud moment for every Indian as rocket lifts off from Shriharikota (South India). A massive step towards learning about red planet. This news prompted me to consider the current and future role of learning activities undertaken by people and organisations. Learning is acquisition of new information through practice or experience[1] and it occurs in response to a need or problem.

2013-10-25 18.55.17-1

During my MBA lesson at MBS Manchester, professor Norman Longworth describes the stages in human learning as “Information Ladder”. According to the ladder, a learner moves through the following progression to construct ‘wisdom’ at the highest level from ‘data’ at the lowest level:

Data -> Information -> Knowledge -> Understanding -> Insight -> Wisdom

Whereas the first two steps can be scientifically defined, the upper steps belong to the domain of psychology and philosophy.

According to Sherry L. Willis, a renowned researcher from US, long-term learning activities is the ability to acquire and retain relevant information and to solve problems. Problem solving involves assessing the present state, defining the desired state, and finding ways to transform the former to the latter. Decision-making refers to the evaluation of possible solutions and the selection of one for implementation[2].

A major difference between experts and novices is in their possession and use of two forms of knowledge: declarative and procedural knowledge. Declarative knowledge involves knowing what facts and information are relevant in solving a particular problem[3] .It is one’s knowledge of the subject matter. Experts have the ability to select quickly the most relevant information for a particular problem, obviating the need for a more exhaustive and time-consuming search through their declarative knowledge.

Procedural knowledge represents the individual or organization’s understanding of how to go about solving a particular problem—how declarative knowledge relevant in a particular situation can be combined to produce a solution[4]. Often the procedural knowledge involves performing a set of operations or following an algorithm.

Individuals and organizations that are new to Agile and Lean may spend much time developing or discovering a plan as they go about solving a problem. An agile expert is quick to develop an appropriate plan to use relevant information and solving a particular problem. The expert “plugs in” the relevant information to the plan or script which helps you to gain knowledge and apply with greater efficiency.

Please contact us and see how our experts can help you and your organization with learning Agile and Knowledge Management .

REFERENCES

  1. Howard and Howard, 1997
  2. Reese and Rodeheaver, 1985; Reitman, 1964
  3. Anderson, 1985; Chi, 1985
  4. Anderson, 1985; Chi, Feltovich, and Glaser, 1981
  5. Rogers, 2000