A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.

Hot answers tagged

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 ...


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

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...


8

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, ...


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

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 ...


5

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 ...


5

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 ...


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 ...


4

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 ...


4

This is a good question, and there's a great set of answers and comments on the UX SE: At what point in the development process should UX come into play in an Agile work environment?, and here in PM SE there's Where should design be incorporated in an agile process? that also has good information. In my experience leading development teams and managing ...


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

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 ...


4

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 ...


4

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 ...


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

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

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

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 ...


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

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

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 ...


2

There are universal signs of team maturity. Use the Forming, Storming, Norming, Performing model as an example. The stages just in framework give a clue as to what you might see as your team matures. When you just form, you can expect to see civility between the members and high morale, but performance will be low, and direction from the boss will be high....


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

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 ...


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

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible