Part # 7 Points to watch out for when converting from waterfall to agile testing

Agile can be a challenge for the Test Analyst who has been trained and is accustomed to working in the traditional waterfall, Prince 2 environments or using the V model. A tester who finds themselves as part of “the team” using the agile scrum frame work can find that they are out of their comfort zone and may feel a little exposed. We recently held a meeting with a group of Test Analysts and asked them to identify what areas of our scrum implementation the needed to be improved and what areas they thought were going well. The key points identified are listed below.
Possible areas to Improve
50% said there were:

• No proper test management processes.
• Not enough sharing of information across the different groups (group = testers, product managers and developers).
• No re-use of test scripts across the different on-line products using the same backend systems.
• 25% said that:
• Being left out of emails containing relevant information to the sprint.
• Changing requirements half way through a sprint and not being clear on the actual change.
• Test work not being prioritised enabling the tester to know what order to test tasks in.
• Tester work is 1 to 2 sprints behind the development. (....Need to read the what done really means)
• 100% stated that:
• There was a lack of written requirements to test against, not enough detail in the requirements resulting in no real understanding on how a feature should work. Also a lack of forethought on features causes problems later on in th sprint.
• No formal tracking of defects: only the tester is using the defect log and changing the status.

Areas that are going well:

• 100% agreed that:
• Definition of sprint cycle.
• Sprint planning and pre-planning meetings.
• Communicating daily with developers.
• Good visibility as to what is coming up .
• Agile process being well implemented- everyone understanding the business benefits of agile.
• 75% agreed that:
  Close working with developers and business owners
• Good use of the impediment log
• Agile process being well implemented: everyone understanding the pros and cons of agile.

Tips for those new to the test agile role

If your thinking about joining a company, as a tester from a waterfall/Prince 2 background, that works in an agile way or your current company is planning to implement agile then I would recommend that you think about the following:

1. Make sure that you attend the sprint planning meetings and wear your 'Business Analyst' hat – make sure you gather requirements that will enable you to write short test scripts and therefore test each backlog item and task. If need be arrange (with the Scrum Master and Product Owner) a follow-up meeting to clarify the requirements.


2. Don’t be shy in raising impediments – it’s the Scrum Masters job to ensure that all impediments are removed so that “the team” can successful carry out their work. Impediments can include "I need more details on how this function should work."


3. Review, on a regular basis, the product backlog and create and maintain a query log that maps each backlog item – this will help you when your in the sprint planning meeting to ask the right questions at the right time.


4. Keep a defect log during each sprint - add those defects that are not cleared at the end of each sprint to the product backlog.
   

See also:
Agile Testing is not for Dummies
Agile requirements are barely sufficient!
Agile Testing
Why Testers should be in at the start

Part #6 How Everyone Can Get Involved in Agile

I mentioned in an earlier post that I was adopting scrum (an agile development frame work). At first implementing scrum identified quite a few issues (mainly bottlenecks) with in the organisation. However the past few weeks have witnessed a turn around – all of a sudden it seems that everyone wants to get involved and be part of the scrum process.
So how do you (as a ScrumMaster/Product manager) broaden the influence of scrum so that all the product stakeholders have the opportunity get involved at the appropriate points in time?

1. Make it easy for anyone (Sales, Product Marketing, Information Architect etc..) to contribute to the product backlog. This can be done by placing the backlog on a shared drive or document management system. I’m currently using SharePoint 2007 as an interim solution before we implement Team Systems.


2. Communicated the dates for sprint pre-planning, sprint planning and reviews along with the start and end dates for the sprints.


3. Invite those stakeholders whose backlog item(s) have been selected (during the sprint pre-planning meeting) to the next sprint and the daily scrum meeting.


4. Invite the same stakeholders to the sprint review where the selected feature(s) will be demonstrated along with the other features.

Some may ague that all the business stakeholders should communicate their ideas to the product owner and he/she alone should attend the various sprint and scrum meetings. However it has been my experience (to date) that the product owners are often too busy (not to say that Product Managers/ScrumMaster are not). Therefore assisting the Product Owner by implementing the 4 steps above will go a long way to ensuring that your implementation of scrum will be successful. The one key point is to ensure that the product owner takes full responsibility for selecting and prioritising the product backlog items.

Part #2: Agile meetings run by an agile chairperson

All of us have attended many meetings during our careers, some good and some not so good. The idea of the sprint meeting: where hands on stakeholders (product owner(s) and technical team) meet for 10 to 15 minutes each day, stand up around a white board and answer 3 basic questions:

#1 What did you do yesterday (reporting back on the commitment you made the day before),
#2 What are you planning to do today (today’s commitment) and
#3 Is there anything stopping you fulfilling your commitment.
Ranks high in my book as a good way to run a meeting to get an understanding of the status of a project, it's: concise, precise and efficient. These meetings are co-ordinated and arranged by the scrummaster (Product or Project Manager).

Sprint meetings which are an essential part of the agile scrum framework.

Sprint meetings are not too different from many typical management meetings that we attend – ironically, these meetings are not conducted in an agile way or form part of an agile framework. These meetings have very firm agendas where each item is time-boxed. It's the job of the chairperson to firmly keep the meeting on track – the final agenda item is traditionally 'any-other-business' (AOB ) which is usually time-boxed at round 5% to 10% of the total meeting time. Some chairpersons will do a 'round robin' in place of AOB – giving each person time to raise any issues they may have (this too is usually time-boxed to 5% to 10%) not enough time to tackle any real issues of concern.

It goes with out saying that the way you chair and organise a meeting depends a lot on the type of meeting, the aim and circumstances surrounding the meeting and the people who will be attending.

For regular team meetings I prefer the more flexible agile approach where the chairperson sets the agenda, gives plenty of opportunity for those attending to add agenda items, publishes the agenda before the meeting and then raises each agenda item in turn but allows the team to divert onto other topics (irrespective of whether the item is or is not on the agenda). The chairperson tactfully pulls it back on track if the discussion does not seem to be adding value to the team or department. Running a meeting in this fashion does take a bit longer (probably up to 25 - 35% longer) however the benefits outweigh the cost.

Another way to run an agile team meeting is to do away with a formal agenda. The chairperson (departmental or team leader) opens up and tells the team what their issues, concerns and achievements are. Then they open up the floor so that others can contributes and share their plans, concerns, achievements etc... I’ve been in teams where this method has been used and over time it has produced good results.

Team morale is kept high as people value agile meetings as a place where concerns can be raised, discussed and possible solutions and support given. This also has the added benefit in that the chairperson (departmental or team leader) gets to know what individual members of their team really think (people talk more freely when they are relaxed and not time boxed) and an understanding of the true concerns and issues that the department/team may be facing – as opposed to a polished presented one-liner that makes them look good.

I worked with one MD several years ago who calculated the cost (based on everybody's, hourly rate) of our weekly team meetings. OK it had the effect that we become more concise with our comments and therefore kept the meeting as short as possible. However the MD didn’t really know what was going on in the various departments in the company.

To get a better return on investment (ROI) out of meetings takes the initial investment of time, that will give you the scope to chair in an agile way. Agile meetings gives the team members time to talk freely – this gives you the ability to really get to the bottom of what is happening. To get concise to the point status of a project adopt a daily sprint meeting (10 to 15 minutes max) the combination of the two (sprint meetings every day and agile meeting every week or two) will help you run any team and or project in an effective way – insuring that you get the best of both worlds: timely reports and a grasp of the real concerns the department/team are facing - the ultimate result being a better ROI from your team.

See also Product Management Productivity Tip #3: Master Meetings

How Agile is Your Product Management?

Comparisons have been drawn between Prince 2 Project Managers and ScrumMasters. Much has been written about agile software development Vs waterfall with a focus on the developers and testers who actually carry out the technical work. However this blog posting focuses on agile management and in particular ‘Agile Product Management’.

Product Management by its very nature calls for agility. Product Managers, in particular those who have responsibility for the P/L of the products they own, are duty bound to keep their eyes on external and internal moving targets. External targets include: threat of new entrants, bargaining power of suppliers, threats of substitutes, bargaining power of buyers (customers), and rivalry among existing competitors. (Porters five forces).
And internal targets encompass: Requests from Marketing, Sales, Engineering, Legal and Chief Executives.

Product Managers will usually be the mediator between the technical and commercial teams – a kind of universal translator – they will often have to work collaboratively across various departments and business units and manage stakeholders and coordinate various activities.

Most Product Managers do not have line management authority so have to work in a matrix management fashion and yet are held accountable and even responsible for the success of the products. This calls for them to be capable of leading without authority and remain agile as business opportunities are spotted and technical teams are constantly redirected in order to exploit window of opportunities. The Scrum agile framework calls this ‘inspect and adapt’.

“In a recent McKinsey survey on building nimble organizations, 89% of the more than 1,500 executives polled worldwide ranked agility as ‘very’ or ‘extremely well’ important to their business success. And 91% said it had become more important for their companies over the past five years.” (Taken from April’s edition of Harvard Business Review) This makes the Product Manager a real asset to any organisation.

Robert Holler: CEO of VersionOne writes about the five Cs of agile management – I have given a brief overview:

Courage,
Agile management is not for the faint hearted, you should not be afraid to practice, hard work, and failure, especially during the early iterations of software development.

Context,
Steer and manage actions and decisions within an overall business context. Work hard to get decisions about project and business context early.

Course,
Agile working is no excuse for not having a direction and roadmap. Longer range planning is still necessary and valuable. Ask the question where do you see your product in 18 months time?


Cadence,
Also known as rhythm: once the technical team, Product Manager and commercial teams establish and get used to a rhythm they’ll begin to function and produce in a predictable way – rather like a well oiled machine.

Cost.
With Agile software development customers begin to see a ROI with in a few weeks as opposed to many months.

Visit The five C's of agile management for the full script.

A good Podcast on this topic can be found at Product Managent View: Agile Methodologies: How Product Management's role is shifting with Laureen Knudsen at HP

• How agile is your comapnay?
• How agile is your product management?
• Does your CEO or MD know how agile you are?
  **Feel free to share your thoughts.**

Read : Part#5 How to adopt agile product marketing

Part #8 Tips on being an Agile Manager