, , ,

Reducing organisation costs – what would you do if it was your money?

In current economy, managing costs is absolutely crucial in any organisation. Many of us are having to change our spending habits at home, and in work we’re also having to focus hard on cost control. This comes at a time when the wider business needs our support to help deliver what our customers want at a cheaper price.   In most of the organisations, we spend half our life either in meetings or preparing for meetings (what a waste of time?!?).  Therefore I thought why don’t I change the format of meetings and reduce the cost and save some time (and be productive 😉 .  There are few simple measures any organisation can implement and achieve huge cost savings:

  • Avoid overnight stays: No overnight stays, hotel accommodation or rail or air travel should be booked for the same day and meetings should be arranged for the later part of the day so that attendees can arrive comfortably.
  • Events: Large scale events and conferences should be subject to rigorous cost control. Encourage employees to use company’s internal facilities where they can. In addition, attendance at external conferences and external training should be approved in advance by senior managers providing a full justification.
  • Making the most of teleconference facilities: If you’re not in the same building, try to use teleconferencing facilities instead of face-to-face meetings. Conference calls have many advantages – they reduce our fuel costs and environmental impact; avoid the costs incurred with non-productive travelling time; and support our employees well being.
  • Use Smart board or projector: We all print documents for meeting attendees and it get thrown away immediately after the meeting. Instead use Smart board or projector and avoid printing presentations. Advantage – reducing printing and paper costs and environmental impact (10 points for being green and saving trees!).

Few other simple tricks:

  • Recruitment: Recruit people from within the company or encourage employees to recommend their friends and relative. ‘Recommend a Friend’ reward should encouraged to reduce hefty fees of recruitment agencies.
  • Personal equipment: Any unused personal equipment (for example blackberry’s, mobiles or laptops), should be recycled for new starters/replacements wherever possible.

We all need to work together as a team to ensure that we get the maximum value for our money. Tell us what you would do if this was your own cash? We’re interested in finding out how you think we can become even more efficient.

Thanks for everything that you’ll do to help and make sure you keep the ideas coming.

[Contact_Form_Builder id=”1″]

, , , , ,

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.


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.

, , ,

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 .


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

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