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
  • Adaption
  • Continuation
  • Improvement

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

RefactoringModel

Refactoring Model Details

Discover

  • Identify areas of improvements

Analyze

  • Define your goal
  • Collaborate ideas
  • Propose solution

Implement

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

Communicate

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

 

Dictionary meaning of reward is something given or received in return for a service, metric, hardship etc.

In typical reward system one celebrates success of an individual or team based on their hard work or value added to organisation (usually one is rewarded for success). Ceremonies are held and art effects are presented in form of monetary items, recognition certificates and well done emails. In reward communication these keywords are mostly used “going extra mile”, “proactive behavior”, “going out-of-the-way”, “excellent team work” etc.

I understand that reward system plays important role in organisation’s culture and shows that people are treated with respect and valued for their contribution. High point in these ceremonies  are usually individual or a team getting the reward but not the steps that one took to be rewarded (I understand that there are small speeches and emails. But do you really remember who was the top performer in your team 6 months ago? and why they received the reward (ah ha.. a moment for thought perhaps).

This idea has been flickering in my mind that reward system and understanding system are interlinked with each other and by combining these systems we can help teams better understand about the actual behavior that led someone to get rewarded.

Some of the basic characteristics of combined system can be (I call this “Understanding System”)

  • Better recognition and radiation of non-formal learning
  • Spaced learning rather than cramped learning
  • Increased motivation
  • Acceleration in idea generation
  • Increased workplace satisfaction and talent retention

I am interested to know what reward system you have in-place for your team and how is it helping your team to learn, grow and understand the actual behavior that led to the reward?

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

Australia
Kane Mar http://kanemar.com/about-me/ (I did SCM training with Kane)
Rowan Bunning http://www.scrumwithstyle.com/about-us

Asia
Vernon Stinebaker http://www.scrumalliance.org/profiles/16047-vernon-stinebaker

Europe
Jurgen Appelo http://www.management30.com/about-the-author/

USA
Lyssa Adkins http://www.coachingagileteams.com/about/
Tobias Mayer http://agilethinking.net/aboutme.html

Training Companies (I’ve see these groups promoting their training products in conferences regularly)
Agile University http://www.agileu.org/
Agile Academy http://www.agileacademy.com.au/agile/our_courses
Rally Software http://www.rallydev.com/services/agile-coaching-and-training-services
Version One http://www.versionone.com/training/agile_training/
Lean-Kanban University http://www.leankanbanuniversity.com/

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

In previous post I explained just one scenario where lack of user feedback during development can land your project into the wilderness with your clients.

Traditionally in software teams roles like business analysts, product owners and usability specialists are responsible for getting client’s feedback by variety of means. It’s time to empower our teams with new feedback and interface testing tools, so they can grab every opportunity to collect smart feedback data and build great products, save cost with higher client satisfaction.

Let me propose few ideas for software development teams

  1. Get closer to your clients by measuring and reducing feedback loop travel time.
  2. To me feedback is a “Value Channel”, so if you create new channels you’ll increase the value of your product.
  3. Use new tools available in the market to collect your feedback.
  4. Make data based decisions rather than emotional ones by validating your idea.
  5. Client’s time is important and providing feedback shouldn’t be more than 2 clicks away.

List of few feedback and interface testing tools

Verify - verifyapp.com
Notable –  notableapp.com
Bugherd - bugherd.com
Usabilla – usabilla.com

What’s your feedback loop travel time and what tools you are using to collect data?

So why not validate your strategy before or during your project before you spend too much time and money.

Ever been a part of a team where

  • You were handed a UI design on a new project.
  • Your teams starts a project and build what it was asked for.
  • This design came from some other team or group.
  • You built this new application it and tested it (all ready to go).
  • Then the aha moment comes when you present this newly build application in front of your clients waiting for a WOW reaction.
  • Opss… your clients say we needed a Zebra and this looks more like a Donkey.

Did someone missed the point somewhere in the whole process?

You’ve got it right! while you were busy building the perfect Zebra no-one asked users for their timely feedback during the development. I am not saying that’s the case with every team but reality of software development business is that teams always try to make perfect application in the first attempt to wow their clients.

Research shows the more client involvement in the product development the better the outcome. The quick you receive feedback the better position you are in to make changes with less cost and you might end-up close to building the perfect Zebra that your client wanted :-)

Let me ask how your team is collecting feedback from clients and how you are making smart data-based decisions?

In order to build your perfect Zebra you can leverage new tools to collect user feedback, these tools are smart, cheap, scalable and will guide your team to make data-based decissions.

In the next blog post I’ll be explaining more about these tools.

Late 2010 I started a project with my new team, everyone was relatively new to agile development. Although we were defining acceptance criteria for user stories but Product Owner and Quality Assurance team had different expectations on what is acceptable to them in a story. Below was my attempt to highlight the difference between different expectations.

Acceptance Criteria: Usually defines the scope of a user story and product owners expectations. Clarifies the product owners intent and what they see as acceptable for clients.

Definition of Done: It’s how we define the quality of a story, steps we must take to ensure the highest quality work delivered within a user story. This can be a quality agreement between developers and QAs.

Example Story: As a guest user, I want to be able to view a shared dashboard so I can view the latest trends in my industry.

Acceptance Criteria:

  1. A guest user must provide valid email address to access a shared dashboard.
  2. Dashboard access and privileges are correctly matched for a given email.
  3. A guest user must be able to view a dashboard on all supported browsers.

Definition of Done:

  1. No fatal errors in code.
  2. No new notices.
  3. Must have unit tests.
  4. Completed code docs.
  5. Code review finished.
  6. Code checked into the build branch.
  7. Interfaces works on all supported browsers.
  8. Performance checks are successful

Let me ask how your team writes story acceptance criteria and creates quality parameters?

The above comparison helped my team to have a greater understanding of delivering high quality features; it also helped us to create a fun development environment where team members were not getting frustrated over compiling errors.

I am a thinker and collaborator who wants to share ideas, suggestions, notes and provide value to teams out there through my experiences and experiments. My journey to explore new areas in software product development starts from this blog, my medium term goal is to become an agile value coach and systems consultant, long-term goal is to publish my own book about agile product development.

Many teams have started riding on agile band wagon and we are producing Certified Scrum Masters’ per minute but does your team really understands what it means to be an agile? How quickly and easily your team develops new quality products? I might be able to help you with some of the answers.

My plan is to write twice a week and if you see missing posts please do awake me up on @adnanaziz. I’ll tell stories and ideas how I see it, and if you see any value in my posts please do give me constructive feedback.

Thanks for visiting :)