Recently I was involved in a discussion about how to introduce test automation in agile teams. These were the main discussion questions and below is my attempt to answer them.
How can an agile project manager or scrum master directly influence test automation in agile teams?
I believe directly influencing team to implement any improvement doesn’t go a long way unless the change comes from within the team. If team doesn’t think they have a problem then why change to what is already working.
Scrum master is there to facilitate discussions, these collaborative discussions should highlight problems and team figures out how they will solve them. Scrum master should be focusing their energy on removing any impediments that team faces when they are implementing their chosen solutions.
How do you introduce and improve the level of test automation in agile teams?
Identify what is the core problem and by solving it how you will help your business, clients and ultimately team itself.
Once can help team members to think in a structured manner, so they understand their current state, desired state and steps between them. Here are some of the steps to think about.
- Problem identification
- Building understanding
- Seeding ideas
- Iterative implementation
Try running a The A3 Process workshop with your team. I found this a very effective tool in solving complex issues in structured manner.
Once team understands the core problem and knows to solve it then tools, languages, processes, frameworks, artifacts, ceremonies and metrics are primary factors in big scheme of things.
I hope this helps!
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
- 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?