Agile testing Vs Traditional QA

 

Exploratory testing   : Business requirements on an agile project may not be as concrete as requirements on a traditional project; agile methods accept that change is a healthy and real part of software development. This means that test case generation may not be as cut-and-dried as it was in the past. Exploratory testing is an essential skill to uncover additional considerations for the product owner to evaluate.

Automation

Agile emphasizes automating as much as possible, but many teams struggle with when, how much and what tools to use. While continuous integration (CI) is an accepted developer practice, agile testing takes the lead on incorporating automated acceptance tests and creating regression test plans as part of CI.

Communication

Traditional QA engineers tend to rely on documents. Agile testing QA engineers don’t get a big requirements document as a basis for test cases and don’t get three months to write test cases before they see a working piece of code. They jump into the communication stream, which may be verbal, written or virtual, and assimilate the information they need.

Challenges with Traditional QA:

· Significant delays between when software is written and development receives feedback

· Defects found late in the process can have major implications when changed

· Changing business requirements affect test cases that have already been developed

· Siloed communications create risk that different groups may have different expectations of the final product

· Quality suffers and many QA activities get left out when testing is the last activity before a fixed release date

Benefits of Agile Testing:

· On-going feedback to developers allows testers to ask the right questions at the right time.

· Early identification of dependencies, technical or testing challenges and roadblocks.

· Embraces change as a healthy and real part of software development.

· Team collaboration helps everyone work together toward a common goal.

· Quality comes first because final acceptance criteria are established prior to the work beginning.

Learn more about Test First programming, and how to transition from traditional testing to agile testing.

Agile and Post-Its

For many,  Agile projects and Post-Its are synonyms, and do you agree this is a misconception ?.
This misconception has gone to such an extreme that, some believe that if you are not using post-it notes then you are not Agile. This looks funny for many Agilists, but this belief is true with many newbies.  One might be interested to understand the origin of this misconception.  Let us start with Information radiators.

Information Radiators

Information radiators are not a new concept. Lean thinkers and Toyota teams have been using this from many years. This concept was popularized in the Agile world by  Alistair Cockburn through his book Agile Software Development.   Since Post-its are handy and easy to use they became popular as information radiators across the globe.

In my opinion, Information radiators are just like any other tools. As the Agile manifesto says,
“Individuals and interactions over process and tools”.   So, one needs to be cautious of using the tools appropriately.

Now we know that Post-Its are just like any other tools. One should be cognizant of their usage in Agile projects. Even though, I have taken the example of using Post-Its here, this is applicable to all tools. Let us see some uses of Post-its.

Teams use Post-It notes to display

• the status of User Stories (Analysis, Design, Build, testing, etc)
• the quality stats
• Impediments/Risks/Issues
• etc.

My experience says that teams reject tools or the tools become unusable if

• wrong tools are used even in the right context
• If the right tools used in a wrong way

Especially, tools play a key role in large scale and long term Agile projects.

Large Scale and long term Agile projects

In the long term projects, over use of Post-its leads to what I am terming as “Post-It Noise”. The wall not only gets cluttered, but people will stop updating the walls.  There are a few who have reported stress due to the cluttering of wall due to unplanned growth of Post-its on the wall. 


I am not against using the Post-it notes  however one needs to be cognizant of  maintainability of them on the walls.  A wall with a beautiful display of Post-it not only adds value but gives a pleasant look.


  http://ericlefevre.net/wordpress/2007/11/17/reflecting-on-our-open-space-technology-event/

Summary

• Use Post-It notes based on need. If the teams are comfortable using flipcharts, White boards, let them use it. Don’t force people to use Post-It notes for every task.
• Arrange Post-its or cling on sheets in a pleasant way
• If you find the teams not updating the wall, do a retro and see if the wall is really adding value

Useful resources

• Visual Display of Quantitative information provides an overview of communicating the data effectively in a graphical way
• Visual Management of Agile Teams
• Trusting a yellow sticky ? Good luck with that
  
  
  
  

Velocity : Myths and Misconceptions

Velocity is one of the simplest but powerful tool to predict the future completion date of the project.

What is Velocity ?

Velocity is the capability of a particular team to deliver certain set of requirements within a specified duration.

It is very important to note that, this is true for a particular team with a fixed duration.  If the team and duration changes then the velocity changes automatically.

Based on my past experience interacting with several teams, I found that following misconceptions misguide the teams.   As an Agile coach or Scrum Master, it is very important to help the team to understand the true meaning of Velocity and drive away the myths and misconceptions.

Myths and Misconceptions 

Wrong	Right
Velocity is productivity	Remember,  Velocity is not productivity.  Productivity is how busy your team is. When some one is measuring productivity, they don’t measure the value generated out of it. Productivity is also measured against a standard.  However, Velocity is for a particular team, particular context and in a specified duration.  Velocity could be tied to business value.
Velocity Standardization	Many leaders think of standardizing velocity across multiple projects and sometimes throughout the organization.  This is totally wrong. As said before, each team is different, trying to enforce velocity of one team on another results in increased stress, loss of morale, productivity and finally loss of value to the customer.
Converting Velocity measured in Story Points to an absolute number in Person days	I have seen many Scrum Masters trying to convert the Velocity measured in Story Points to Person days. For example, 80 Story Points = 60 Person days.  Again, this is wrong. The above conversion basically freezes the delivery capability of the team upfront.  If the team is new to a technology or a business domain, the capability to deliver would be less. By freezing the story points upfront, the new team would struggle a lot and will get stressed out.
Comparing Velocity among teams	Since Velocity is specific to a team and within a context, it does not make sense to compare the velocities between teams.  A team comprising of Oracle Experts working on Oracle technology obviously will fare well as compared to a team of  fresh out of college put on a similar Oracle project.  Velocity of both the teams would be different. Never compare velocity between teams

Large Scale Agile development– Key danger and few tips

The biggest danger to large scale Agile development spanning multiple releases  is complacency, and especially around following Agile practices.
For example: After doing the same daily stand-up for hundreds of times, a few teams get bored. They start skipping the daily stand-ups or try to tune in their own way.  
It becomes Scrum Master’s responsibility to ensure that the team gets back on track by identifying the team issues.  I have always found that talking to the team in a non-hostile way helps in identifying the root cause.
It is very important for Scrum Master not to force the practices but sell the idea through discussions and by empowering the team.
Here is a good article summarizing few key ideas for empowering the team.

Coming back to the point of complacency, how to avoid one ? 

Here are few tips 1. Change the structure or time or the location of say Daily stand-up after few months.  Instead of doing at 9 AM in the morning, you could do it at 3 PM. 

2. Identify and rotate the leaders to run some of the Agile practices.  Rotate the anchors. Give a chance to the back bencher to anchors the practices.  

3. Add or rephrase the questions for the daily stand-ups.

4. In one of the large scale Agile development I was leading, initially teams were using the questions “What is working well and Not working well” as part of Retrospective.
After a few months, I changed the questions to “What is working well and What we should do differently ?”
We started using Ideaboardz  for some time and switched over to “Discussion boards”.

5. Do a retro on these practices to get feedback from the team to assess their energy levels

One cannot avoid complacency in large scale and multi release Agile projects, however, by keeping the eyes and ears open, one could mitigate the risks.
Photo courtesy: http://www.freedigitalphotos.net/images/Ideas_and_Decision_M_g409-Solution__p23490.html

Impact of different cultures on Scrum meeting and Retrospective

Scrum meeting and retrospectives are the two key Scrum practices. These two practices provide an opportunity, for every team member to express themselves.  Expression is not only the key message here; the team is allowed to share the impediments, bottlenecks, risks, issues and what is not working well for them.

Photo courtesy:http://www.freedigitalphotos.net/images/Other_Objects_g271-Traditional_Chinese_Knots_p59170.html
Silent Cultures
Some cultures don’t encourage expressing negative feelings in public.  Even when there is terrible issue in the project, the team members will keep saying everything is working fine until the issue becomes so big that it is not solvable. It is not that they want to hide anything, it is just that, they want to silently solve it by themselves.  This cultural problem aggravates if the team is working in onshore/offshore mode.  The onshore members have to rely on the voice or emails, when they cannot see the body language of offshore team.  If you are working on one of those projects, then one would see a no-issue period for few iterations and then a huge panic after that.

Even during retrospectives, one would see a big list of all the good things, and a small list of improvement areas.

Impact: Continued suffering by project members and since issues are detected at a very late stage, additional effort and stress gets added.

Expressive Cultures

Team members from expressive cultures would challenge every issue and bring out impediments upfront.  This provides an opportunity for all the stakeholders to address concerns upfront.  If you are working on one of those projects, one would end up having a long list of impediment issues and retrospective items to cover.

 

I see more pros than cons here. Some times decision making becomes difficult as the team members would end up spending a lot of time debating issues.

Photo courtesy: http://www.freedigitalphotos.net/images/Mature_Men_g217-Expressive_Old_Man_p46710.html

Hierarchical Cultures
Hierarchical cultures have a  strong command and control style of leadership. Typically, a lead represents the entire team and makes all the key decisions.  The team members just follow the directions from the lead with no questions asked.  The team members will be like “Blinkers” on horses eyes.  They can only see or hear few things from a window given by the lead.

Impact
>>  The team members will only share impediments/blockers that are allowed to be shared by the lead.
>> The team members find it difficult to make decisions on their own
>> The impediment list from Scrum meeting and the feedback items from the retrospective will have a pattern of certain issues only. Because, these are the only patterns that are allowed by the lead to be shared to the outside world.

Photo courtesy: http://www.freedigitalphotos.net/images/Other_Business_Conce_g200-Organisation_Chart_p36927.html

Let me know if you have other stories about the cultural impact on Agile practices. Am happy to publish it.

Top 200 Blogger

I found out recently that  My Agile Blog has been rated as one of the Top 200 Blogs on Agile. 

Check this link out: http://agilescout.com/top-agile-blogs-200/

Right now I am on 155 .   This number could change depending on so many parameters.   I am excited though.

What’s the first Decision? Implementing Kanban vs Scrum

Happy to publish this guest post by Michael DePaoli

. Author’s bio at the end of this article 

What’s the first Decision? Implementing Kanban vs Scrum by Michael DePaoli

If your development team or manufacturing team is considering moving to using Kanban vs. Agile Scrum, one of the biggest decisions is choosing the right agile development methods for the job. Let’s discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
2. Establish and respect WIP(work in progress) limits in the value flow
3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams.  These outcomes in turn destroy brands, ruin company reputations on Wall Street,  increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

 

 

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability.  But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice:  ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

• Your organization’s product development and sales culture,
• The nature of the demand for service from product development,
• The competency of your organization to plan and execute change, and
• The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Image Courtesy: http://www.freedigitalphotos.net/images/Ideas_and_Decision_M_g409-Choices_p23497.html

Over his 26 years in IT, Michael DePaoli’s experienced has included serving in different traditional roles in highly respected companies. The roles have included analyst, software engineer, quality engineer, development manager, project manager, Director of Engineering, VP of R&D, CTO and Consultant in companies, such as American Express, Sprint, Deloitte Consulting, Sapient, Knowledgepoint, Adobe Systems, AOL, NetApp and VersionOne. Michael works as an agile / lean coach and product consultant with the VersionOne services group.