Recently I attended Agile Conference 2018, in Islamabad as speaker. This was very well organized event by Pakistan Agile Development Society.
I will share detailed experience later on. For now, I am sharing copy of my slides that I had the opportunity to present in regard to selection of Agile Methodology to ones’ cultural and organizational needs.
AgileConference18_Presentation
If you have any question or want any help on this, please reach out at abkhalid@gmail.com
Its been couple of years, that I have had the opportunity to write & share something. I hope I am not that rusty!
It was early 2010s when we started hearing and discussing about Agile in larger audience. Especially in Pakistan. Initially people thought, it’s a ploy to remove testing resources altogether, as there is slump in markets and companies can’t afford to have “freeloaders”.
I remember, having multiple discussions with my friends and telling them, relax man, we are here to stay. But deep down, I had an itch, what is this “new way of development” where no testing, or documentation is required.
Let’s back up a little bit. In traditional software development lifecycles, there was always a Testing Face, and the biggest question was QA v QC or Verification v Validation. But we knew whatever the distribution, but we will have our time for each project, where we will be working on the application/software as per our own understanding of the requirements. We (some of us thought) were too good in business side of things, so we only knew what client wanted and devs where there to only put blocks together).
By having, ”our time” (in other words testing time or cycles) there was a clear divide, it was Testing vs development.
It was then, and presumably with more common understanding / knowledge of Agile Methodologies, with mantra being one team, one would assume that this would have gone. But no, it hasn’t we still keep fighting the battles, we still have battle lines drawn.
I have been scratching my head and trying to find out the root cause. And up till today morning, I was thinking we need more coaching for our team members. But something clicked, and that is, we the dinosaurs need to change first. We still keep fighting the “Us v Them” battles. Even though our resources have been put in same teams, but we the “Managers” are still holding the rope tight. We still keep on believing that they are our resources. We keep on encouraging “our” resources only. In reviews we try to find faults with resource from “other” team. Try to hide the issues of one’s own resources.
But we must realize, as soon as you step in to world of Agile, the resource managers are not managers, they are parents, that have to let their children decide their own path, and to quote a windows phrase “Sit Back and Relax”. Let them make mistakes and learn from them. Help them if asked, don’t go running to find the issues. The more you let them be on their own the more they will learn.
So agile coaches, please sit together and sort us out. Make sure we believe in one team concept, rather than preach only.
I have done my Manager (Traditional Manager) to Manager (Agile Coach) Journey, have you? More on this in my next blog.
Important Announcement: if you are facing any issue regarding Agile Testing, Testing Organizational changes, HP’s products for Application Life-cycle Management, Functional or Regression Testing and/or Performance Testing, please contact at abkhalid@gmail.com , I will try my best to help you out.
You can also share your opinion and if any particular topic you want me to cover I would love to do it up to best of my knowledge.
In recent years it has been observed that more and more organizations are moving in to a very agile environment. Now people have discussed thoroughly about new roles for each resource across the board, where traditional Developers, project manager, testers, analysts, system engineers, support staff and others go. One role that has not been discussed and has been taken as peripheral, infect in some cases as obsolete is of Traditional Testing Department Lead.
As with the case with every other Testing Lead, I recently have had to face the same dilemma (infect I am still going through this transition), where I have been able cope better is due to my role of Test Management Consultant (for HP Testing Software) in my previous organization.
Traditionally it has been observed that the role of Test Lead is of a watch dog, which is going to give final authorization weather to move forward with application or not, weather the application is as of Client’s requirements, weather all needs, wants and desires of client are in place. This role was evolved from a person to identify the screen look-n-feel and document writer about 15 years back. And had its most influence over the last 5 ~ 10 years.
But now as Agile is starting to be implemented more and more, these above responsibilities are delegated to “testing” resources part of a feature/scrum team and scrum masters.
So what now for Test Lead, as he cannot delegate work, he cannot authorize or sign off an application release. Most organizations have taken the easy way out to get rid of these high earners and giving all their powers to scrum / feature lead.
My new organization has bucked the trend, to laugh out loud, they hired me.
In first few days I was of the point of view that somebody somewhere in higher-ups screwed up big time and sanctioned the hiring of a Testing lead, completely forgetting the change in organization that was going to take place.
But no, they have hired a “Traditional Testing Lead” to do very “Un-traditional” job. My new role specifies that I don’t indulge on go live or resource tasks but to be a consultant with in an organization for testers.
To help them out, to train them, to enhance their capabilities to be able to work as individuals in scrums and be the “watch dogs” within the scope of their respective scrum or feature based team.
So here I am re-inventing myself. I will try to share more information over next couple of months.
Important Announcement: if you are facing any issue regarding Agile Testing, Testing Organizational changes, HP’s products for Application Life-cycle Management, Functional or Regression Testing and/or Performance Testing, please contact at abkhalid@gmail.com , I will try my best to help you out.
You can also share your opinion and if any particular topic you want me to cover I would love to do it up to best of my knowledge.
Most of us have been exposed to project that never follows actual project plan; the changes can be new features, new add-ons, defect fixes or new integrations. For every test manager these projects take a snow-ball effect, that is they keep on growing along the way, and you are never sure what to expect from them. And to make the mater worse more rapid the changes or defect fix, lesser the duration between the builds. But the area to test keeps on increasing. Another factor to consider is the trend of software development companies to “fall” in to Agile Development, where they “think” everything must be parallel.
Now what it do to test managers is very scary, you cannot get the automation kick in, as application is being updated regularly, you cannot add more resources, as “You don’t need more resources, you already have got it tested”, while if they do not get it all tested, you get to hear, “Mr. what are you doing, look there is very important bug your team missed”.
To tackle all this I have made my policy that for a project that is behaving like this (let’s say every new build is within less than two weeks of other) I usually deploy two resources; both resources do test new features for first week. For next week depending upon the available time, needs to change test cases, I on daily basis try to cast a net on areas that are near to new features, where one resource test the application, and other update the test data and test cases for next build.
And for last couple of days before the next build, we do a strategic exploration of application, which is for every build we select one or two modules and do exploration for the application.
This is not the ultimate test management process, but honestly since the advent so called agile development, and lack of cohesion between builds and marketing team’s insistence of new build every other day; this is the best I could devise in 5 years of my test management.