Accepting change and responding to change is a true Agile spirit in my opinion. During product development projects; user requirements change, UI changes, client expectations change, system behavior changes and to accommodate these changes your codebase consistently has to evolve.

Continues code refactoring is reality in Agile teams, a great piece of code in this sprint might be refactored in next sprint.

How Agile team deals with refactoring depends upon the

  • Maturity of software engineering practices
  • Desire to learn new things
  • Exploring areas of improvement,
  • Tolerance in product management team about consequences of patchy solutions
  • Culture of doing the right thing for the client

On daily basis developers spot code smells and identify areas of improvement, small changes get implemented quickly and bigger changes get discussed, sometimes compromise solution is chosen otherwise features delivery or project due date gets the hit. Among these developments the communicating what has changed usually slips through the cracks because everyone is so focus on feature delivery.

Recently I ran number to workshops to identify challenges we face in continues refactoring and how to approach refactoring in a structured and systematic manner. We came up with a refactoring model that any product development team can follow make code refactoring more effective and easy to understand.

Refactoring Model


Refactoring Model Details


  • Identify areas of improvements


  • Define your goal
  • Collaborate ideas
  • Propose solution


  • Time-boxed implementation
  • Improve quality and/or performance


  • Radiate knowledge
  • Record achievement
So how you team is approaches refactoring and what systems you’ve in place?


Historically most companies use stock standard individual performance plan processes and tools (monthly meetings, Microsoft Word templates, SMART goals). Common issues are difficulty to maintain and version control Microsoft Word template, monthly meetings become upwards reporting meetings to line management, multiple document copies fly around via emails and mostly performance plan gets created at the start of the year and the next time this document is looked it’s at the end of the year.

Performance plans are all about accomplishing inspiring goals. It is time to get creative, innovative, collaborative and introduce agile methodology into individual performance plans. This year I am assisting my team to turn individual performance plans into agile performance plans.

Here are few things you can do to turn individual performance plan into agile performance plan.

  • Performance Stories: Turn goals into performance stories with clear acceptance criteria.
  • Product Owners: Ask your line manager to become a product owner of your agile performance plan.
  • Less Context Switching: Use agile development tools than no-one has to switch a new system to manage goals.
  • Value Steams: Create inspiriting value steams and let your goals flow thought them e.g. (Thinking, Inspiring Goals, Doing, Done)
  • Lean Principles: Use queue limits for goals and concentrate on finishing the highest priority item
  • Performance Plan Sprints: Turn your monthly individual performance meeting into performance sprint planning and retrospectives.

So how your team is creating individual performance plans this year?

Since the start of agile performance plans in my team I’ve noticed increased participation from team members, new value streams are opening up, collaboration has increased, instant feedback on goals is possible by using Agile tool notifications.

Example of Iron Man Performance Board

How to turn your individual performance plan into agile performance plan

The Exercise:

Last year I ran a Marshmallow Challenge with development teams in Cyberjaya at Experian Malaysia. Majority of the team members worked together in an agile environment for a year.

The Idea:

How agile teams respond to a challenge when they have to do a continues collaboration in order to deliver a working product at the end of time-boxed iteration.

The Outcome:

Our game workshop was full of fun and we learned a lot about collaboration and delivery. Here are the few highlights.
  • Not a single team was able build a standing structure at the first attempt
  • Then we paused and identified areas of improvement
    • Importance of  collaboration
    • How to identify and remove hidden assumptions
    • Test early and test often
  • In the second attempt most teams were able to build a successful structure that can hold a marshmallow

The Question?

How are you testing level of collaborate within your team and what you are doing to improve it?

Workshop Time-lapse

Last month I contributed towards the agile forum that was collecting a list of good agile trainers and companies. Given below is the list of people I  recommend based on the following criteria.

  • Personally met them in conferences/workshops
  • Read about their work regularly
  • Did my Agile training with

Kane Mar (I did SCM training with Kane)
Rowan Bunning

Vernon Stinebaker

Jurgen Appelo

Lyssa Adkins
Tobias Mayer

Training Companies (I’ve see these groups promoting their training products in conferences regularly)
Agile University
Agile Academy
Rally Software
Version One
Lean-Kanban University

If you know good Agile trainers and companies do share with me and I’ll update this list.