Skills/personalities best suited for roles
Scrum Master - Trainer and manager thought QA is a good role to be the Scrum Master on the team even though the trainer did recognize that in a team with a ratio of 4:1 devs to testers, it throws more on the testers plate when they already have enough to do. I have two issues with QA being the Scrum Master and I would like to see a website make recommendations on the following. I think there has to be a skill set requirement and a personality match.
On skill set, I have been with my IT company for less than a year and have sat in our planning and daily standups and when the developers start talking about architecture, refactoring and get it into implementation details, that's when I go "huh?" My company uses many leading edge technologies and anyone in the IT field knows is you close your eyes for 6 mos, your skills are already out of date. The type of programming I do is the kind you learn in a "teach yourself X in 21 days" and is very rudimentary. For example, words like Flux, are still a mystery to me. We recently cited at Scrum training the lack of documentation, knowledge is with a few key individuals, and little or no on-boarding. I would be afraid as a Scrum Master that a developer would raise an impediment and I would not know what to do with it because I lack context. In the absence of another developer who needed to work the issue, I could see myself saying to that person, "go talk to so and so, they have an issue" rather than try and relay it and muck the message.
On personality, I think a Scrum Master is a coordinator of people. As a task-driven person, I find that very draining and not my style. You need managerial skills which I never had nor want.
On Product Owner, which we don't currently have, we have Product Managers that write our stories and provide feedback at review meetings and daily stand-ups (when they do attend). It seems to be like our teams' UX contact who do user studies, research, and are knowledgeable of business are a good fit for the PO role. As a QA, I give recommendations to the PM (and or PO if a when that role is implemented) on what high priority bugs should be pulled into the next sprint and keep the backlog of those items ordered.
Doug,
I'm not sure if I agree with your Scrum Master skills assessment.
A Scrum Master nurtures a team to higher and higher performance. This involves many soft-skills like empathy, encouragement, relationship-building, and understanding of organizational sponsorship and structures to help resolve team impediments.
Whenever in doubt, turn the issue over to the team. Ensure they take ownership of it. In your example where a developer raises an impediment, ask the team what should be done. A Scrum Master isn't responsible for resolving impediments, but is responsible for making such impediments visible within the organization so that they can be addressed.
Our code is too buggy for me to take on any more work. I think I serve my company and developers well by finding all these issues. Think of all the support I provide for trainers, doc writers, and customer care eliminating the need for customer calls. Isn't that what it's al about any way? Serving the customer and making a company profitable? Scrum teaches that QA primary role is not finding bugs but that's all I do. Developers are too taxed to write unit tests and knowledge sharing of tools like Code Climate doesn't happen. How can we get there? Just seems like we chase our tails sprint to sprint with refactoring and getting stories that are too big. What can we do to take the paradigm shift and truly implement Agile? The only way I see is to hire more people and let bugs go to the field so that we may spend more time with up front planning narrowing scope of stories, documenting architecture, spreading tech leads to review changes that would affect other apps, taking time to automatic testing, build up the unit test suite. But people leave and many engineers don't write stuff down.
Doug,
Just to recap a few of your points:
Our code is too buggy for me to take on any more work
Developers are too taxed to write unit tests and knowledge sharing... doesn't happen
...getting stories that are too big
It seems that many of your issues relate to inefficiencies in how you work. Inefficiencies, mind you, that are being exposed by trying to work Agile-ly.
Scrum is not about working more than capacity, yet that is what I am seeing from your explanation. Team members are barely able to come up for air, and quality is suffering because you are trying to work Scrum into a fixed scope/timeframe.
Keep in mind, traditional project management (waterfall) allows you to adjust any of the 4 project variables (time, cost, scope, quality) in order to "stay on schedule". With Scrum, the only variable that can be changed is scope. Time is fixed (length of iteration), cost is fixed (stable team), and quality is fixed. There simply is no "shortchanging" quality in Scrum. You are experiencing the ramifications of poor quality practices.
Letting bugs go to the field is simply kicking the can down the road. Stop hiding the problem, and start correcting it. You will need to go slower, because you were never as fast as you thought you were in the first place. Don't you think you will go much faster with cleaner code?
How are you "serving the customer" by delivering untested, buggy code? How does your company expect to turn a profit with such a poor product?
Why are your stories too big? Who is grooming them? Why are they being accepted by the team if they are too big?
Why are you dependent on engineers "writing stuff down"? Isn't all of the information needed for a story captured in it? If not, it sure needs to be.
Start to follow Scrum, instead of SINO (Scrum In Name ONLY). Learn about Lean waste and ways to improve your processes. Start building higher quality into your work product. Begin reducing the mountain of technical debt that you are dealing with.
There is no quick fix, just a lot of hard work and patience.
Hope this advice helps. It is just the tip of the iceberg though. Good luck.
It comes down to working with a bunch of cowboys in a very unstructured and volatile environment both quality wise and in building and deploying. The product that I am getting is no where near QA ready and I end up spending my days thrashing with developers and build issues. It is very draining. I don't think the developers have a good idea how to estimate; often they get into the story and realize 3 days into the Sprint that it's another week of effort. Instead of having the power to stop and split the story up, we raise the issue to our manager who is supposed to groom these stories and just continue chasing our tails. We recently had to rip the entire flux of our product and replace 21%+ of the code and all the bugs that I am finding; it's like starting over. Why am I finding so many issues? Again lack of unit tests, dev qa testing, trouble with IE, limited knowledge in the team, overwork, stress, etc. etc.
Sounds like we are not communicating....
- i want developers to document their design so when the system goes down, I know what services/processes to check without feeling totally helpless or pinging a chat room
- I want to understand the reason for major architecture refactors and test implications
- I want documentation so when there is talk of flux, apache web server, apis, front-end, back-end specifics I understand what the hell is being talked about (thus my apprehension about being the Scrum Master) - we cited at a recent Scrum training, that our on-boarding is basically non-existent
- i want to attend architecture reviews and listen to the conversations for buggy areas
- I want formal code walkthroughs and again listen for buggy areas
- I want developers to have more unit test and have me review them
- I want developers who are familiar with static analysis tools to find time to give brown bags so we in QA can learn how to use these tools. I am fine with teaching mysefl provided someone provides me a road map, order, timeline, priorities, and where to find the information instead of this"figure it out yourself", keep things to myself job security bullshxx.
- I write detailed manual test cases
- I went and met the tech writer my first day onthe job, affirmed what an awful job they have, and always support them
- I take Cucumber scripts and write API docs for the gherkins on the conditions necessary to run to document all my leg work and save the next tester from the grief
- I comment the hell out of Ruby scripts because that's what I was taught 28 years ago in Comp Sci. I can't remember what I had to eat two nights ago. I document for myself and for the troubled soul trying to navigate through all the cryptic Selenium system messages and come on board quickly.
I have seen people dismiss Waterfall because it took too long for a product to get to test. I think that is ridiculous and preached to my mentees about being there from day 1 and being a part of the process from requirements, design, data design, code inspections, white box test review in addition to writing a test plan and scripts. There were a lot of good benefits in Waterfall that are lost in SCRUM that I think are the causes of a lot of issues at my place of work.
And do you think I feel good saying all this? Absolutely not! But I feel like someone riding a mechanical bull swinging my hat yelling YEEHAW!!!!! There is only so much a person can take. Others can just say it's a 40 hour a week job and I am not getting upset if they are not going to train or pay me more. Guess I need to think like that too....
BTW, I have close to 25 years experience testing. Had a great performance review. Been told my internal and external customers that "I am the best tester they ever met" The unstructured, thrashing environment is just driving me crazy. I have no QA manager to vent to.
Doug,
If your environment is volatile and unstructured, then I sympathize with your pain. To me, what you describe is very dysfunctional and in no way reflects an Agile approach.
Unfortunately, it seems you are now venting about your difficult situation, without any clear question or request.
Poor estimation, poor quality, overly-demanding schedules, and a mountain of rework based on these poor practices. An Agile mindset, and Scrum in particular, can definitely help. However, without executive-level support, such a transformation will never take place, unfortunately.
Again, good luck to you.