22
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 ...
14
With no prior experience this is likely to be a tough ride. Listen, listen, listen to your team and others. There is a lot to learn for you. No two teams or companies are the same. Even with prior experience there is not cookie cutter approach to being a development manager or a project manager.
What I typically do when I start working with a new team is ...
13
Your assistant did nothing wrong. You wrote he does not know company policy. You cannot hold him accountable for what he does not know. He, while you were on vacation, kept the ball rolling. He made a decision and he acted. He should be commended for his eagerness and willingness to put his neck on the line for what he thought was a super idea. Those ...
13
We have an index card on our board, that permanently sits in the Backlog, labelled "Technical Debt". Any team member can grab a post-it note and write down T.D. they think we are collecting. For example, if they know that a coding decision could have complications later down the line, we stick it on the Technical Debt card.
At the beginning of every sprint ...
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 ...
10
First, consider yourself lucky that you haven't yet signed the formal agreement. It's a lot easier to bring up bad news to a client early on than it is at the end, when the client is ready to take delivery.
At such an early stage, you shouldn't need to just eat the cost. At this point the client hasn't lost anything. If they want to get the project done ...
10
Missing or incomplete requirements is one of about 1,000,000,000 random variables that will impact you during the course of a complex project, both favorable and unfavorably affecting your cost and schedule estimates. Many of these variables, you won't even see and, thus, will not have any opportunity to ask who is at fault on this exchange.
This is ...
8
I cannot add too much to the previous two answers by @the_reluctant_tester and @John, except 2 things:
I got the impression that this will be your first job as a leader. If so, I strongly recommend to find a mentor in your organization, because without a mentor it will be a tough job. Maybe the guy who gave you this job can be a good candidate or a fellow ...
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
Conflicting or inconsistent requirements are not just part of an IT project but span across all types of projects. You can be certain, no matter how hard you try not to, that you will create a requirements baseline with a host of inconsistent or conflicting set of requirements. On top of that, the solution derived to meet a requirement could break another ...
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, ...
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
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
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
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 ...
5
Now
I can't give you perfect advice on how to solve the current problem.
David and thursdaygeek seem to have covered this well enough, and I agree with thursdaygeek that getting your report involved in fixing their own mistake will be rewarding for everyone involved.
But I'd definitely shield them during and after the process, and take the mistake upon ...
5
First on my list would be to take some time reviewing your recent bugs and doing a root-cause analysis on how the bug made it in. That can help you decide on which solution(s) make the most sense for you to implement. As far as things I would likely implement in a similar situation:
Design reviews - As a short term solution, I would suggest simply having a ...
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
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
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
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" ...
Only top voted, non community-wiki answers of a minimum length are eligible
