28
TL; DR
Your question embeds some false assumptions about the linear nature of testing within an agile process. A mature agile team with cross-functional skill sets treats development and testing as intertwined activities rather than as sequential ones.
You should strive to integrate development and testing so that they are not fundamentally separate work ...
12
One approach I have seen work is to initially stub the backend functionality before doing the detailed development work.
These are the steps the team takes:
The backend developer defines an API that the frontend will use for the feature
The backend developer builds a very simple stub that allows the frontend developer to make API calls and get back ...
8
The simplest answer to this will likely be the answer you least like. Don't...
In the last fifteen or so years we have seen an ever increasing level of transparency in the work place. This crosses all industries, all job levels and all work styles. Agile hasn't gained the traction it has because it is the best methods of development ever. Agile has been ...
8
They could be doing a number of things. What they should be doing depends on your organization's Scrum/XP maturity but here are some common items:
QA work - yes devs can QA, whether thats writing new automated tests, upping existing test coverage or reducing test complexity, doing manual testing, or performance/load testing, devs can and should QA. The ...
7
In Team Foundation Server 2013, there are 3 templates available for team project by default
Microsoft Visual Studio Scrum 2013
MSF for Agile Software Development 2013
MSF for CMMI Process Improvement 2013
All of them agile enough to accommodate your needs, but I think the first two are more convenient.
The Scrum template is designed to support the Scrum ...
6
It might be how you're suggesting these changes.
It probably has nothing to do with your position (QA), per se, but more to do with the fact that some new guy is coming in, telling everyone that what they're doing is all wrong (despite not having been around long enough to understand why it's done that way).
In addition, you could even be seen as a threat, ...
6
TL;DR
The original question was tagged Scrum, so my answer will focus on how Scrum expects routine and non-routine changes to be managed. In brief, Scrum embraces change, but encourages the Product Owner to plan refinements for future iterations whenever possible.
By treating refinements as new work, the framework encourages ongoing collaboration between the ...
5
I think the reason you've not found much written is that when you get down to the cores of agile, the difference in projects is not all that pronounced. What you want from a project is what really drives the type of implementation, not what you are creating.
Predictable Schedule, Flexible Scope- Use Scrum
Volatile scope, short delivery windows- Use Kanban
...
5
This is based on personal experience, so if it differs from your own, feel free to jump in.
Development - refers to the primary implementation of new projects. Once an initial development project is complete, and the clients/stakeholders have accepted it, then you will typically move into a new phase--either maintenance or enhancement.
Maintenance - refers ...
5
I don't believe it is possible to sort by status changed date. However, given that your requirement is "to have a list of the JIRA tickets that are not moving from one lane to another so that I can intervene on those tickets", you can find all tickets that have not moved in X days. For example:
(status = "In Progress" AND status changed to "In Progress" ...
5
TL;DR
The canonically-correct solution is to put someone with business analysis skills onto the Scrum Team in a Developer role, and then cross-train the whole Scrum Team. Cross-pollination of skills enhances the capabilities of the Scrum Team and the Developers, and builds T-shaped people.
Including someone skilled in business analysis on the Scrum Team also ...
4
TL;DR
Do you think it is worth to put up such a title formalism in place?
No. A title is rarely a unique identifier across bugs, nor is it likely to communicate enough on its own to justify the constraints.
Titles Should Be Meaningful
While I agree that titles should be meaningful, it is very difficult to create a short formalism that could be ...
4
When I moved into my current team we were in this situation, however I had the benefit of coming in as Application Development Manager. You will face challenges without the authority to make decisions, but a lot of what I suggest below doesn't have to be driven from the top down. To be honest, everything I proposed I asked the team, and got their buy in ...
4
I would suggest taking a look at MS kanban 1.0 template. Which is more of a continuous delivery process instead of iteration based approach.
4
This question raises a big question to me - is this actually a project in itself, or something that will be altered as part of other projects? If the latter, it may not need anything around it other than source control.
Removing the TFS element from this question, Kanban is an agile methodology without time boxing that could be applied. These situations ...
4
Short answer
Don't formalize. Communicate more often.
Long answer
I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.
"emergency" fixes needed overnight
If you mean that the moment the customer finds bugs, ...
4
Focus on quality and estimates
You identified four problems. Of those, I would view the following two as your main issues (long hours and missed deadlines are likely resulting from these):
Quality of your code is dropping: When the quality is bad, you end up doing a lot of unplanned work. This results in long hours and missed deadlines not to forget the ...
4
The contract type is another factor to consider. A firm-fixed price (FFP) contract can provide you the opacity which is your stated desire. The specification is set in the statement of work or statement of objectives. The product is evaluated for acceptance against the specification. To cut against opacity, the buyer can require "key person" clause requiring ...
4
"Typically for a team of 3 to 4 developers, there would be 1 QA resource"
That's your problem there. There are three roles in Scrum, Product Owner, Scrum Master and Development Team Member. Your Development team is meant to be a multifunctional team working towards the same goals. It's fine to have people with different skills (in QA, in development), but ...
4
Anybody in the team can make suggestions for how the team can perform better, also new team members with a QA background. There are, however, two things working against getting your ideas accepted.
Change is hard. If ideas are not backed with authority (either formal or informal), then the team often finds it easier to dismiss the new idea than to make the ...
4
I would recommend you guys hire an Agile Coach or Scrum Master, at least for a six months period. One of the four parts of the agile manifesto is Individuals and interactions over processes and tools so answering your question, there isn't a right or wrong way of doing thing but a way that the whole team agree on following.
Just to get the ball rolling, let'...
4
If this is the US Federal government, you are in the middle of some serious fraud. This isn't something you fix, this is something you report. Call the whistleblowers hotline and look for a new job.
I think each department has its own process how to do this so you'll need to look that up.
4
I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to ...
4
There are two answers here - the Scrum answer and the my practical answer.
In Scrum, there are three "accountabilities" (prior to the November 2020 revision, roles) on a Scrum Team - Scrum Master, Product Owner, and Developer. A team has one Scrum Master, one Product Owner, and everyone fits into one of these buckets. However, if there are multiple ...
4
I have seen many business analysts work well in Scrum teams.
The three biggest challenges for them are typically:
Reaching a clear understanding of roles and responsibilities with the Product Owner
Adjusting to the just-in-time nature of Scrum - looking to add detail at the latest possible moment
Becoming good at responding to change - taking feedback from ...
3
I'm going to describe my experiences from the point of view of a project manager in Information Services. Some of the specifics might not exactly match your specific environment, but the principles are still the same.
This sounds like a classic case of breakdown in communication between the business resources and the technical resources. This can also be a ...
3
I found that walking around and talking to each person is the only effective way to get a full status update. the write it up and send an email.
Unless you're really good at it, don't use electronic means to record the status; pen and paper is the fastest and least annoying method, as far as those giving the status are concerned.
Work from the bottom up, ...
3
I would agree with Lunivore and SBWorks - their inputs are from both an academic and from a professional industry-based perspective - seasoned with common sense and an understanding of the English langauge
(which is pretty LOW in the UK, Australia, Canada, NZ and the USA - I constantly see immigrants who have a good laugh at the local's language disasters)
...
3
What you're talking about is creating a 'methodology', and yes, it's a good idea.
The methodology is created for the reason you mentioned - so that (most) anyone can step in and keep the project moving, because it follows an established process and requirements.
As for what to include - that depends on the project type and what your company feels is ...
3
Do not take on any more extra work, there is a temptation but if your organisation is brought into line then the money will come. Just keep enough to maintain your cash flow. Greed is a very destructive force in business.
Use something like a SWOT Analysis to ascertain your current position.
Produce a Risk Matrix to find where the emergencies are so you can ...
Only top voted, non community-wiki answers of a minimum length are eligible
