14
TL;DR
A Sprint enshrines your empirical process by providing a maximum delivery cadence
It increases communication and alignment
It adds some predictability to the unpredictable nature of software by evening the batch sizes.
A Sprint is a container for planning!
While the Scrum Guide says that you must deliver working software at least every 30 days there ...
11
Lean is to Kanban as agile is to Scrum. One is a concrete implementation of the other.
Using the term "lean kanban" is just an attempt to court favour from Google/Bing for keyword density and is the result of copywriters rather than an actual thing.
All Kanban is Lean... But not all Lean is Kanban...
9
Zsolt gave a really great checklist for tackling any new project. I'd even point traditional project managers at this. I'm going to try and provide some additional Scrum focused detail.
Brand New Team, Brand New Scrum Master:
If everything is brand new, you're going to want to set up your ceremonies and cadence right away. At this stage most agile experts ...
9
Do you do diligence and figure out as much as possible about the project, the people, the customer, and the stakeholders on your own.
Talk to each team member face to face about the things above, do not tell them anything besides your background. Let them tell you as much as possible on their own.
Mark the common thing you learned from your discover process ...
8
It looks like you have a process for doing your work that has intermediate stages where other people need to work on each work-item or card. And you have no control over how long they might take to get them done.
This is typical of a "multi-team" Kanban boards where intermediate wait states between teams can take too long and essentially behave like ...
7
They have a concept for a piece of software, we do some analysis and agree on reasonable budget and start agile development.
Good.
However once the client starts to see the product they cant (sic) help but tweak endlessly
Also good.
despite our protests
Why are you protesting? If you're in an agile environment, you are supposed to embrace change, ...
7
There is some grey area here, but let's start with a clear answer to work from. Epics are a derived idea from User Stories - specifically an epic is just a big user story that you've broken down into smaller stories, so to address what you're asking it makes sense to walk through the breakdown of the user stories (and therefor, epics). I don't know your ...
6
TL;DR
There's a lot of disagreement and confusion about the practical interpretation of these terms. I wouldn't get too hung up on hair-splitting as long as your Product Owner, stakeholders, and development team can all agree on some working definitions for your organization.
Minimum Viable Product (MVP)
Minimum Viable Product is a term most frequently ...
6
TL;DR
A kanban board is only a tool to visualize work. What’s missing is a continual improvement process.
The Kanban Board Isn’t a Process
A kanban board is a useful tool for visualizing work, but it will not inherently solve a process problem for you. However, it may surface the dysfunction, and often helps stakeholders to identify where work is getting ...
6
You can tactfully explore what changes have been made to improve the product or the team based on these metrics in the past few months. If these measurements have led to improvements or more effective decisions, they are not vanity metrics. Your newness can be a benefit here. You can say "Sorry, I'm new. Can you help me understand how the team or leadership ...
5
From past experience it is very difficult to get someone to update one piece of work in two different places, so I would recommend having a single team board where all items are visible, but you can filter down based off of the current need. It also fits two of the main purposes of kanban as well, which are:
The kanban methodology relies upon full ...
5
Kanban is a lean methodology focused on creating continuous flow of work while eliminating waste (muda) in the system. There is no difference between Kanban and Lean Kanban.
Where there are some differences however...
Kanban for software development differs slightly from the classic Lean Kanban formulated by Toyota in the 1980's and used in manufacturing ...
5
TL;DR
If you're doing commercial R&D, then you should focus on directed development and manage the project around the research methodology chosen. Less directed research should simply be time boxed (financially or otherwise) so that the necessary reporting deliverables are handled appropriately.
If your research is directed, it should then be ...
5
In Kanban, the board is meant to visualize your process. By visualizing your process and tracking work through it, it is easier to spot your bottlenecks and challenges.
So, the direct answer to your question is: No, the columns are not set. Yes, you can use those SDLC titles IF that is how you currently work. Now, a word of warning, if that is a whole ...
5
Tough question; To my mind there are two choices:
Communicate the opportunity cost of vanity metrics to management. Measure the impact on project schedule/cost/quality by diverting resources away from production to ego stroking. (opportunity cost) On the other hand, if they define ego stroking as part of the scope, then stroke egos.
Help the team to ...
5
First of: thanks for the link to the vanity metrics blog. It was an interesting read.
Second point summary: monetize the costs
Second: I dealt with the same issue at my previous company. I created the report because I was asked to do it. After the first time I asked why I was creating it because it took some time to create (I could spend 3 to 4 hours ...
4
You may find under your situation that a Scrum Sprint model does not fit well. It is just one way of doing things. Perhaps you are looking more of a Kanban approach
As for the usefulness of a sprint itself, if a team of people are able to work together to complete a piece of functionality that meets the sprint goal then it can be quite rewarding for them to ...
4
If I would be the leader, I would just say. "Stop it. Don't waste time for this report".
Yes you could and this time you may be right. But are you always right?
The strength of a Scrum team is that it pools the knowledge and understanding of several people together. Decisions are made by consensus as a result of producing strong arguments or by adapting a ...
3
This sounds like your development team is not being allowed to sufficiently discuss the stories in the product backlog prior to moving them into the sprint or iteration backlog. The development team should be able to take stories that are either too big or too small and decompose or aggregate respectively. The team should be discussing this during sprint/...
3
I'd start by moving to a physical task board. Tools can be great force multipliers. However if you start in a tool, you will often get influenced by the tool and end up doing process by tool. This is happening to my teams at AOL now and I've got teams experimenting with physical task boards for day to day and Jira just to document the work for official ...
3
If you're getting rotten code, then the team's not really completing
the stories, are they? I assume your definition of Done includes
having sufficient unit tests and acceptance tests, having them pass,
and having well-structured (i.e. refactored) code; if it doesn't, I
recommend you change it so it does.
I'm guessing that if the focus is on doing ...
3
Minimum viable product has absolutely nothing to do with usability or marketability. It is the smallest thing you can do to get validated learning against a hypothesis. That is it. It doesn't even have to be a piece of software. Oftentimes, a well formed question and a storyboard will suffice. The point isn't that what you've created is marketable, but that ...
3
If the Client wants formalised sessions then the best option is to go to a formal session from Scrum.org or ScrumAlliance.
https://www.scrum.org/courses
https://www.scrumalliance.org/courses-events/course
Both sites have a ton of resources for your slide deck.
Regards
3
As Daniel has said - Kanban says "Start from where you are" - meaning, start with your current process, don't change anything. Simply visualize it and then gradually change it as the team identifies the need for improvements.
If your current process is "Backlog, Defining, Designing, Testing, Deploy" - you can start with that and use it to track each ...
3
TL;DR
You can look at data and use inductive reasoning to formulate a hypothesis, or use deductive reasoning to define your product goals. Note that you must have a hypothesis or goal to test and measure; otherwise, you're performing the equivalent of asking random sea turtles which shoes to make for the world's fastest Olympic runner. Even then, you're ...
2
The Poppendieck's defined lean software devlopment in their seminal work, Lean Software Development: An Agile Toolkit
Research has a number of opinions on lean and agile. In a survey on agile methodologies, lean was considered a type of agile methodology. (see "Empirical studies of agile software development: A systematic review")
Lean has been shown in ...
2
I would encourage you reading this blog post as it offers a variety of practices that are meant to promote planning on demand, team involvement and rapid delivery. Also, in my opinion, you might perform all three types of meetings for team collaboration: planning meeting, daily meeting, retrospective meeting. Such approach will allow you to communicate and ...
2
I would recommend a mixed practice called scrumban.
As you need to manage small group of people who are doing project and support work at once, you would not want sprint based approach like in scrum because your support will ruin them. Or you cannot split those two because you do not have clear team boundaries between support and development. Scrumban ...
2
Here is a good definition and explanation of differences: http://www.romanpichler.com/blog/agile-product-innovation/minimum-viable-product-and-minimal-marketable-product/#comment-4050
The minimum viable product (MVP) is a powerful concept that allows you to test your ideas. It is not to be confused with the minimal marketable product (MMP), the product with ...
2
I would suggest that Lean software development as discussed at length by Mary Poppendieck and Tom Poppendieck is a methodology closely related to the Agile family of software development methodologies such as Extreme Programming and Scrum, each with its own design emphasis, rituals and community. However, at the heart of all Lean/Agile culture is the core ...
Only top voted, non community-wiki answers of a minimum length are eligible
