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 Details
Identify areas of improvements
Define your goal
Improve quality and/or performance
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.