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 ...
10
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
Your team is the benchmark.
If last week you weren't doing Test-Driven-Development, but you all agreed that was something you wanted to change for the next go-round, and you did...there you go. If you decided to give it a go - but didn't - well, you didn't follow through...not the end of the world, but could probably do with some follow-through and ...
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
Formal Definitions
At this time, there are no formal definitions of maturity across agile methodologies. However, the Capability Maturity Model Integration (CMMI) framework uses five levels to define process maturity:
Level 1 - Initial (Chaotic)
Level 2 - Repeatable
Level 3 - Defined
Level 4 - Managed
Level 5 - Optimizing
If you're looking for a formal ...
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
Walk the Process
Don't be lazy; walk the process. You're trying to find a technological solution (e.g. cameras) rather than just following the current process to build your diagram. Especially for deeper detail levels such as hand-tracking, you will find it difficult to accurately identify waste without actually performing the process and getting a first-...
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
Value is the high quality outcome of an organisation that the customer is willing to pay for.
Important notes:
there is a difference between output and outcome. The output is the product, the service etc. your company is providing. The outcome is the positive difference the outputs make
the value is always looked from the customer's perspective
3
Convergys reported successful Six Sigma implementation
Convergys is a customer care company with call centers in many countries. I happen to know that they implemented Six Sigma in their call centers (service-oriented environment) in India and reported major savings. Here is a list of Lean Six Sigma success stories, including the Convergys' one. You might ...
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 ...
2
First, a modern testing tool could greatly improve productivity. Microsoft Test Manager, when fully integrated into a Team Foundation Server installation, is my personal favorite. There are others however that will probably give you much similar results.
That being said items 1-9 on your list appear to be a fancy way of saying "things you have to do to run ...
2
I am of the opinion that it is more valuable to compare your team's current maturity against where you want to be rather than against where you started. To this end:
Define a reasonable, achieveable future state. This definition needs to be based on your business requirements and not on what a text book says. Key to success here is engaging your team in ...
Only top voted, non community-wiki answers of a minimum length are eligible
