, ,

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.

, ,

People arriving late to Standups/Scrum Meetings?

I have seen many Scrum Teams have trouble getting to their Standup on time, and being properly prepared. My suggestion is to get hold of some kind of “cheap simple noise device” (eg bell, hooter, drum, cymbals; NOT a mouth-contacting whistle/trumpet/vuvuzela).

Step 1: Make the warning noise of your choice 1-2 minutes before the meeting starts. (and maybe another 1 when the meeting actually starts!) Many team members, especially the usual latecomers, hate this approach, but it is highly effective. Especially when you try

Step 2: After 1-2 Sprints, select 1 person (somehow) who is still late/latest to the standups, and give them the power of making the warning blast – make sure the team knows who the week’s/sprint’s “victim/cop” is, and make sure they know just how vitally important their new responsibility is. You even get to take the device over to them at the right time, just to help them if they need further motivation.

Step 3: Usually after 2-3 Sprints, everyone is at least getting to Standups on time. If all is excellent, you may wean (or not) away from using the “noise device” – depends on whatever team culture has evolved in response.

Happy Scrumming!!!!

, , , ,


Recently overheard heated debate on code refactoring. I felt they were mixing up refactoring with rework and agile model was being blamed for not designing upfront therefore need for code refactoring. This resulted in waste of time, organically grown-poorly-commented-complex- code that needed retesting.

So, why and when do I refactor my code?

Simple answer is, when you are sure that you will never ever have to touch a piece of code again, there’s no need to re-factor that code.

But most of the time, you will have to touch it again because you will have to add features, fix bugs or optimize it.

  1. To eliminate/reduce the “Code Smells”
  2. Easier for any developer to understand the code
  3. To make it maintainable.
  4. To increase cohesion and to reduce coupling”

I don’t usually recommend refactoring just to reduce code smells, or make it ‘nicer’/more maintainable. I do suggest you refactor your code, when you need to fix bug, and you want to leave code in better shape than it was before. Other reason is when you want to add functionality, and it would be hard to do without refactoring. Third reason is to make code more testable. Sometimes refactoring will help you to learn the code which you don’t understand 🙂

Refactoring is used to pay your Technical Debt. Code refactoring is a necessity of observing the fact that change is inevitable. It’s principal goal is to enhance the current code or design in order to make it amenable and congruent with new functional or non-functional requirements or to make it more tolerant to change.

Examples of scenarios where refactoring may be necessary:

• Introduction of a new business rule that requires the current design to be abstracted to a new level;
• Recognition of the fact that the current design could be modified in order to better observe the SOLID principals of object-oriented design;
• When code testability needs to be increased—this relates to 2 above.

While you are refactoring
• Avoid code duplication when I see it (following DRY principle-need to write a blog on this too)
• Simplify the code (remove unnecessary ad-hoc complexities, KISS- keep it simple and stupid)
• Remove old/stale/deprecated code (cleaning waste, once the old code is replaced)
• Eliminate side effects
• Generalize and reuse existing code
• Reducing complexity of individual functions – makes testing easier
• Eliminating repeated code – reduces opportunities for mistakes

And finally, Its not waste of anybody’s time!!!!


Estimating Data Warehouse Project

I have always wondered what is a realistic expectation for the time to design and implement a data warehouse? I am managing a Data warehouse project in an agile environment where the key idea is to deliver business value frequently. The initial estimate to deliver complete DW was in 6 months which I was always felt was too short. There are few challenges with this project;

  • Team members were new to agile development with strong opinion about non agile delivery of DW
  • Legacy systems which has grown organically over a period of decade( partially documented)
  • Source system which was build using non English language
  • Key business decisions were being made using spreadsheets produced by few people

In a meeting with management, team committed to deliver this project in 6 months which I felt was bit ambitious. With the help of Google I came across few estimation techniques which I will be referring here. In any traditional organisation the CIO/CFO would be interested in knowing how long will it take and how much will it cost. It’s a chicken and egg kinda situation, Since the project is not approved therefore you cannot hire experts to estimates and without an estimate your CFO will not approve the project. In order to make life easy I decided to divide this problem into two parts:

  • Pre approval estimates
  • Post approval estimates

After some research I came up with the following simple tool( thanks to experts who shared their knowledge).

[ws_table id=”6″]

This will give you a high level estimate which can be used for approval from Project sponsors. Once project is approved, start building your product backlog (detailed requirements) then go through agile estimation process to come up with better estimates. If you need more information or want to organise a workshop to estimate your product back log the get in touch with sales team(Sales@capriconsulting.co.uk) and they would be able to help you in organising it.

Happy estimating



Is there a point in story point estimation?

Is there a point in story point estimation? How do we estimate accurately?

This is a relative size of the story compared to other story estimated by the same team – it has nothing to do with who is implementing it and how long it’s going to take. Story points are relative estimate, so that you know that 5 point story will take approx. 5 times longer than 1 point story.
Benefits are

  • Team’s velocity can be measured
  • Allows team to plan future sprint without over/under committing and forecasting total number of sprints. As a result no unrealistic expectations are placed on the team
  • Helps team to focus on completing dev and testing in the same sprint
  • Helps teams reach a sustainable pace and due to this the business starts to believe in the teamHours (or ideal hours) are more about time estimation. It can lead to several problems:
  • Your “hours” are not the same as mine. It can be harder to make team estimate during release planning.
  • It’s easier to make relative estimates and then calculate team velocity in points.
  • Stories are usually decomposed to tasks for the sprint. These tasks can be implemented by different people. So total effort is not simply calculated as sum of task estimates.
Usually it’s recommended to make story estimation in points for release backlogs and in hours for sprint backlog.
  1. Story points are a pure measure of size and complexity
  2. Story points are relative (say, with respect to the simplest story) and so have a much longer shelf-life
  3. Story points are usually independent of who gives the estimate (as in, an experienced developer and an apprentice can usually agree on something like complexity fairly quickly)
  4. Story points avoid the need for discussions like “what are *ideal* hours, really?” or “My ideal hours are different from your ideal hours, stupid.” These add no value.
  5. Story points don’t influence behaviour (e.g. Parkinson’s Law)
  6. Story points are easier to work with – especially when product owners start to wonder why “3 ideal days take a week…”
  7. Story points are more fun – especially when they’re in units like gummy-bears, polar bears, or other endangered species.