Velocity is not a valid measure of team or process improvement.
Velocity, especially when it is based on Story Points, is extremely unstable. By itself, Velocity doesn't reflect the capacity of the team, but capacity will limit Velocity. It's also easily disrupted by changes to the team's way of working (which includes the definition of what a Story Point ...
How to roll out pairing in a Scrum team?
I am afraid there is no right answer to this. It all depends on the existing team dynamics. Nevertheless, what is almost always relevant is to understand whether pair programming is something your team will benefit from? If you have good reasons for it, discuss them with your team during the retrospective meeting and ...
My devs are not used to unit testing framework and are still learning
This will improve over time as they gain more experience.
There are only 2 of them and each with their specialty (Front-end and back-end) so they have to do both the coding and the unit testing for their side of the stories.
That is absolutely normal. Who else would write tests? Even if ...
Based on your question, it seems likely that you are practicing command-and-control project management rather than functioning as a coach or process referee within the Scrum framework. You should fully embrace the principles of the Agile Manifesto and empower your team to find their own solutions within the twin constraints of the Sprint Goal and the ...
To pair or not to pair is a decision that the team should make and own. "Rolling out" any technical practice, and especially one that brings with it such strong personal preferences as pair programming, is pretty much guaranteed to backfire.
To encourage people to try pairing, I would keep an eye out for situations which commonly breed misunderstanding, or ...
Both Developers and Executives Broke the Agile Contract
It was due for a release tomorrow but, as a result of a review by management, needs reworking. This will undoubtedly add a lot of time onto the estimate for release.
You have a basic process failure if the first time your management team reviewed the product was shortly before release. In particular,...
The below is predicated on the assumption that you work in a complex, adaptive environment where more is unknown than known when it comes to the value your work creates:
There are books and books on this kind of stuff, and companies that make millions consulting on agile enablement, but it really boils down to how willing people are to embrace the Scrum ...
I think the crux of your question may actually lie in questions you posed in a comment, rather than in the question itself:
Do you find it acceptable that release dates are not met?
The answer is... it depends. It really depends on the situation; on the project itself. If it is a purely internal project that is a 'nice to have' or some such thing? Yes, ...
Scrum is not Agile. :) It is one way to do agile, it doesn't fit all situations.
Based on what you've described, a straight Kanban approach is going to work much better for you. When supporting a live service, when you need to make a change, it is often something that needs to be changed "yesterday". Waiting for the next sprint to add it to the backlog is ...
While I can't give you a specific idea about it being too early, I'd suggest strongly making sure that your team fully appreciates the concepts of agile development and also wants to have a useful process in place.
Right now I am working on a team of 4.5 (3 full stack devs, an intern, and me, the PM/BA). I wanted to get us started with the agile concept ...
Your Scrum transition plan looks good
Here are my suggestions:
Get some training: Any team transitioning to Scrum will struggle with getting stories ready, estimating, release roadmap and so on. So, send some of your key people for training. And ask them to come back and train the rest of the team.
Create feature teams: Not component teams (such as a back-...
If you reduce or remove a non value adding activity the overall outcome won't change, but the process time will be reduced. Often the non value adding activities take some time, but they can be caused by unnecessary transportation, doing things again etc. In Lean production they are called waste. A couple of examples:
corrections: when you have to fix ...
Your concern is absolutely correct. Velocity as a team improvement metric is problematic because an improving team will often see their velocity increase but just because the velocity increases doesn't mean the team is improving.
What you really want to look at is value delivered. There are a number of ways to assign value to work. If your team is already ...
Having 10 people on a scrum team is a stretch. The recommended size is on the order of 4-7. Remember that scrum is about communication, and communication scales as the square of the team size. On a team of size 10 the communication costs will be very high, with some people over talking, others tuning out, and others being ignored.
I would suggest ...
The drawback is that using this approach the velocity will be lower and if this is very unusual situation only some sprints will be affected.
How to track such a issues so that our velocity measure will be correct?
If you didn't complete any of the work you committed to in the sprint because of this issue then your velocity is correct even ...
Kanban for maintenance and Scrum for development
What would be the best way to manage this team so the load is level
across all resources, we work at a sustainable pace, and we have a
somewhat-defined goal to guide our development efforts?
If I were you I will start with the following straw man proposal and refine it from there:
About half the ...
Excessive complexity in processes is called "Red Tape"
You can see the Merriam Webster definition of red tape here: Official routine or procedure marked by excessive complexity which results in delay or inaction.
The term originates from the red tape formerly used to bind legal documents in England.
You can see the Wikipedia definition of red tape here: ...
I would start by asking: What is the report and who is it for?
There's no singular right answer - I don't think it's safe to say that "the Scrum Master should create all reports on behalf of the development team" or "the Scrum Master should create no reports on behalf of the development team".
A Scrum Team contains three roles - Product Owner, Development ...
You can do a pilot of the Kanban method
Welcome to pm.stackexchange!
As @nvogel suggested, Kanban method may be suitable for your type of work. Again, as he suggested, you should let the dev team 'to self-organise and allow them to choose a way of working that will suit them'.
However, I would suggest that you run a pilot of the Kanban method that will give ...
One approach you could try is to have the QA working ahead of the developers.
It would work something like this:
Back end devs write stubbed API calls that mimic the behaviour of the finished functionality
UI devs create a boiler plate front-end that calls into the API (getting results returned from the stubs)
At this stage there is no implementation code ...
Start with Source Control
Recommending specific tools is off-topic here, but from a software project management standpoint (and even from an engineering point of view) the correct answer is likely to be using effective source control.
A source code management (SCM) system like Subversion or Git is built to do exactly what you're trying to do: track changes ...
Agile methodologies already have a self-improvement process built in. So applying BPM to any agile method itself is superfluous.
However, you may want to apply BPM to the whole company, to see if your agile method actually is the optimal approach to your companies goal.
Based on past experiences, I would agree with the other posts above and recommend starting with a flow-based approach like a kanban board for the ongoing support apps, and maybe look at Scrum for the ones in heavier ongoing/feature development. I would also recommend starting with a board that matches your actual step by step flow and not an idealized flow, ...
Quality Audit is basically seeing if you are following the defined process. A Process Analysis is examining what you do and identifying aspects that could be improved.
As an extreme example, in a Quality Audit you might have a process that says "Every employee should sleep for 10 minutes per hour" and the Audit would have to confirm it was being followed.
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 ...
Is it or can it be a Scrum Master's responsibility to:
setup/improve a code review software system?
setup/improve the continuous integration process?
provide scripts/macros/helper tools to make the development process easier/more efficient ?
No, no, and no. These responsibilities rest with the self-organizing development team. If you ...
One way to think about project management is that it isn't necessarily about adopting a specific process, framework, or set of practices. Rather, it is most often a tool for managing expectations and making sure that project-related communications are effective.
It is never too early to manage expectations, or to start communicating effectively. The ...
These are some that I have recently listened to. I have put links to Audiobooks. Play at 1.5-2X speed which will help get through them quicker for your MBA.
Manufacturing, but applicable to Software The Goal
How a disaster project is turned around by switching to Agile methodolgy The Phoenix Project
Similar to The Phoenix Project Rolling Rocks Downhill
Tendency to manage an organization by adding more controls, adherence to rigid procedures, and attention to every detail for its own sake.
Red tape is about right, but it refers to the outcome not the process. I found Bureaucratization here. This is the correct meaning but the word is a mouthful and certainly not commonly used.
Don't Just "Work the Story." Work the Right Story!
Your current user story reads:
As a portfolio manager,
I should be able to select list of models from the list,
so that I can create a portfolio.
On the one hand, this story doesn't define a need to select all the models, just "a list" of them. In that case, how many they can select is left as an ...