27
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 ...
15
What the Stand-Up Meeting is For
The Stand-Up Meeting (a.k.a. the daily scrum) is designed to accomplish two main things:
Coordinate task dependencies within the team.
Identify process or resource issues (blockers) that need to be addressed outside the stand-up meeting.
Various scrum practices support these objectives. The individual practices are ...
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 ...
7
Skips the Tools; Build a Process
You describe your current process like this:
Get order, a lot of communication with files that specify the details, delivery, more communication on setup and support. Then it can be years and the software needs to be updated according to new specifications and the communication starts again before a new delivery.
While ...
7
I was managing a team of five developers and we started out with CI using CruiseControl. I am hard-pressed to think of a situation involving more than one developer where it would not be advantageous to do CI. Hudson/Jenkins is a good platform and we later moved to it.
Also, you get A LOT more bang for your buck if you are doing CI against a build system ...
7
First: Document Your Process
We don't do shopping questions here on PMSE, but we're all about process. The correct way to comparison shop for any tool is to document your actual work-flows and project processes, and then find a tool that supports what you are actually doing.
Write down how your team does things right now. If your project is just forming, ...
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 ...
7
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 ...
6
The Purpose of CI for Project Management
While the question as originally posed isn't really an ideal fit for this site (e.g. it's more about development practice than about managing projects) it is nevertheless a useful question when properly framed.
The Value of Automation to a Project Manager
From a project management perspective, real-world projects ...
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 will bet you have more project management going on than what you are giving yourself credit for. The natural tendency of any group of individuals embarking on a task is to form a team, establish roles including leadership, establish rules, establish processes, and figure out solutions. Since this has grown from one week to six months, it shows that this ...
5
There are really two ways to handle this. One is more intentional than the other.
And a bigger reason for it that might get mgmt behind it.
The first is do a "lessons learned" after each project. What went right, what went wrong, what could we do better, what new risks did we identify, etc. During this time one of the things you can review is the idea of '...
5
CodeGnome's answer is about perfect... But here's my 2 cents as well:
Is the daily scrum 15mins meeting mandatory for successful scrum project?
For a successful scrum project, yes. You're not doing scrum if you don't have daily scrum meetings.
For a successful project in general, probably not. People have been successfully building software without any ...
5
The word analysis in SWOT is wildly exaggerated. What you feel is most likely correct: "I really get the feeling that we are going through this process because someone read in a management book that it's a good thing to do"
However, back on topic. Yes, Strengths and Weaknesses are static and mostly internal (unless your team is particularly favored/...
5
I disagree with Deer Hunter almost completely.
The SWOT analysis is a simple and very powerful tool and is an input to so many other pieces of business analyses: product selection, vendor selection, project selection, outsourcing, and insourcing to name a few. It is done at the organization level, and then decomposed at the division level, business unit ...
5
I would be wary about giving an absolute answer to this because the meaning of a job title can vary hugely from organisation to organisation and sector to sector. In my own sector - digital/software development - I would say that Project Coordinators normally report in to Project Managers who may, in turn, report in to Programme Managers.
In my experience ...
5
The answers to those questions depend heavily on your company/institution/hierarchy. I think we can only respond in the context of PMI (although I'd love to hear from a PRINCE practitioner or other non-PMI organization).
Work performed as a project coordinator almost certainly qualifies as job experience towards PMP certification (I'm only hedging because ...
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
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" ...
4
I believe a Kanban style implementation would fit perfectly. Have the PM move from managing tasks, to managing a prioritized list of user stories based on the client's requests. Get the team together once a week or so to break down the user stories into tasks (This should be the team, not the PM doing the breaking. You could also simply have the team break a ...
4
Yes, architecture is vital and Yes to your entire - and very well stated - second paragraph, it changes the relationships and the role.
From the agile manifesto's 12 principles:
The best architectures, requirements, and designs emerge from self-organizing teams.
When a software architect tries to pull rank or maintain status over a good agile team, ...
4
Before going into a system that offers the segregation between a task and an issue, would like to make sure the users are very comfortable with the terminology and, more specifically, when using one or another.
As you pointed, systems usually use the same nomenclature for identifying something outstanding. I believe that's mostly because users don't care ...
4
Bluntly the relationship between the project coordinator function and that of project manager is similar to that between a secretary. The secretary has an excellent grasp on the day to day activities of the task, but has never taken responsibility for delivery.
This does not mean that the project coordinator cannot make the step to being a project manager, ...
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
