Search Results

Search found 54 results on 3 pages for 'kanban'.

Page 1/3 | 1 2 3  | Next Page >

  • Introduction to Lean Software Development and Kanban Systems – Eliminate Waste

    - by Ben Griswold
    In this post, we’ll continue the Lean Software Development and Kanban Systems series by concentrating on Principle #1: Eliminate Waste.   “Muda” is Waste in Japanese. In the next part of the series, we’ll dive into Principle #2: Create Knowledge / Amplify Learning. And I am going to be a little obnoxious about listing my Lean and Kanban references with every series post.  The references are great and they deserve this sort of attention. 

    Read the article

  • Introduction to Lean Software Development and Kanban Systems – Create Knowledge and Amplify Learning

    - by Ben Griswold
    In this post, we’ll continue the series by concentrating on Principle #2: Create Knowledge and Amplify Learning In the next part of the series, we’ll dive into Principle #3: Build Integrity and Quality In. And I am going to be a little obnoxious about listing my Lean and Kanban references with every series post.  The references are great and they deserve this sort of attention.  

    Read the article

  • Introduction to Lean Software Development and Kanban Systems – Defer Commitment and Decide As Late A

    - by Ben Griswold
    In this post, we’ll continue the series by concentrating on Principle #4: Defer Commitment and Decide As Late As Possible.   In the next part of the series, we’ll dive into Principle #5: Deliver As Fast As Possible. And I am going to be a little obnoxious about listing my Lean and Kanban references with every series post.  The references are great and they deserve this sort of attention.  

    Read the article

  • Introduction to Lean Software Development and Kanban Systems – Build Integrity and Quality In

    - by Ben Griswold
    In this post, we’ll continue the series by concentrating on Principle #3: Build Integrity and Quality In.   In the next part of the series, we’ll dive into Principle #4: Defer Commitment and Decide As Late As Possible. And I am going to be a little obnoxious about listing my Lean and Kanban references with every series post.  The references are great and they deserve this sort of attention.  

    Read the article

  • Introduction to Lean Software Development and Kanban Systems

    - by Ben Griswold
    Last year I took myself through a crash course on Lean Software Development and Kanban Systems in preparation for an in-house presentation.  I learned a bunch.  In this series, I’ll be sharing what I learned with you.   If your career looks anything like mine, you have probably been affiliated with a company or two which pushed requirements gathering and documentation to the nth degree. To add insult to injury, they probably added planning process (documentation, requirements, policies, meetings, committees) to the extent that it possibly retarded any progress. In my opinion, the typical company resembles the quote from Tom DeMarco. It isn’t enough just to do things right – we also had to say in advance exactly what we intended to do and then do exactly that. In the 1980s, Toyota turned the tables and revolutionize the automobile industry with their approach of “Lean Manufacturing.” A massive paradigm shift hit factories throughout the US and Europe. Mass production and scientific management techniques from the early 1900’s were questioned as Japanese manufacturing companies demonstrated that ‘Just-in-Time’ was a better paradigm. The widely adopted Japanese manufacturing concepts came to be known as ‘lean production’. Lean Thinking capitalizes on the intelligence of frontline workers, believing that they are the ones who should determine and continually improve the way they do their jobs. Lean puts main focus on people and communication – if people who produce the software are respected and they communicate efficiently, it is more likely that they will deliver good product and the final customer will be satisfied. In time, the abstractions behind lean production spread to logistics, and from there to the military, to construction, and to the service industry. As it turns out, principles of lean thinking are universal and have been applied successfully across many disciplines. Lean has been adopted by companies including Dell, FedEx, Lens Crafters, LLBean, SW Airlines, Digital River and eBay. Lean thinking got its name from a 1990’s best seller called The Machine That Changed the World : The Story of Lean Production. This book chronicles the movement of automobile manufacturing from craft production to mass production to lean production. Tom and Mary Poppendieck, that is.  Here’s one of their books: Implementing Lean Software Thinking: From Concept to Cash Our in-house presentations are supposed to run no more than 45 minutes.  I really cranked and got through my 87 slides in just under an hour. Of course, I had to cheat a little – I only covered the 7 principles and a single practice. In the next part of the series, we’ll dive into Principle #1: Eliminate Waste. And I am going to be a little obnoxious about listing my Lean and Kanban references with every series post.  The references are great and they deserve this sort of attention. 

    Read the article

  • Kanban vs. Scrum

    - by Andrew Siemer
    Can someone with Kanban experience tell me how Kanban and Scrum differ? What are the pro's and con's of each of the different project management methodologies? Kanban seems to be getting a lot of press these days. I don't want to miss the hottest new way of tracking my teams failures (...and successes). Responses @S. Lott - What part of this article wasn't clear enough? infoq.com/articles/hiranabe-lean-agile-kanban/…. Do you have a more specific question? That is a great article but technically no it is not clear enough. That article gives a great amount of detail about kanban (and thank you for it...good read) but it does not specifically contrast Kanban vs. Scrum. That article will help someone like me make a decision but it most certainly won't help someone like my boss or in general someone less experienced! I was hoping for a quick overview of kanban pros and cons contrasted to scrum pros and cons. Thanks though! @S. Lott - Why do you say kanban vs. scrum? What leads you to conclude they are conflicting approaches? Can you make your question more specific? I don't think that they are necessarily conflicting. But they are different enough for a user to adhere to one over the other. Perhaps one fits a project or company better than the other? How would I sell one over the other when presenting a project management approach. Say I went to a company that was currently stuck in the rutt that is "water fall" - why would I sell one approach over the other?

    Read the article

  • Kanban Tools Review

    - by GeekAgilistMercenary
    The first two sessions on Sunday were Collaboration and why it is so hard and the following, which was a perfect following session was on Kanban.  While in that second session two online Saas Style Tools were mentioned; AgileZen and Leankit.  I decided right then and there that I would throw together some first impressions and setup some sample projects.  I did this by setting up an account and creating the projects. Agile Zen Account Creation Setting up the initial account required an e-mail verification, which is understandable.  Within a few seconds it was mailed out and I was logged in. Setting Up the Kanban Board The initial setup of the board was pretty easy.  I maybe clicked around an extra few times, but overall everything I needed to use the tool was immediately available.  The representation of everything was very similar to what one expects in a real Kanban Board too.  This is a HUGE plus, especially if a team is smart and places this tool in a centrally viewable area to allow for visibility. Each of the board items is just like a post it, being blue, grey, green, pink, or one of another few colors.  Dragging them onto each swim lane on the board was flawless, making changes through the work super easy and intuitive. The other thing I really liked about AgileZen is that the Kanban Board had the swim lanes setup immediately.  One can change them, but when you know you immediately need a Ready Lane, Working Lane, and a Complete Lane it is nice to just have them right in front of you in the interface.  In addition, the Backlog is simply a little tab on the left hand side.  This is perfect for the Backlog Queue.  Out of the way, with the focus on the primary items. Once  I got the items onto the board I was easily able to get back to the actual work at hand versus playing around with the tool.  The fact that it was so easy to use, fast and easy UX, and overall a great layout put me back to work on things I needed to do versus sitting a playing with the tool.  That, in the end is the key to using these tools. LeanKit Kanban Account Creation Setting up the account got me straight into the online tool.  This I thought was pretty cool. Setting Up the Kanban Board Setting up the Kanban Board within Leankit was a bit of trouble.  There were multiple UX issues in regard to process and intuitiveness.  The Leankit basically forces one to design the whole board first, making no assumptions about how the board should look.  The swim lanes in my humble opinion should be setup immediately without any manipulation with the most common lanes;  ready, working, and complete. The other UX hiccup that I had a problem with is that as soon as I managed to get the swim lanes into place, I wanted to remove the redundant Backlog Lane.  The Backlog Lane, or Backlog Bucket should be somewhere that I accidentally added as a lane.  Then on top of that I screwed up and added an item inside the lane, which then prevented me from deleting the lane.  I had to go back out of the lane manipulation, remove the item, and then remove the excess lane.  Summary Leankit wasn't a bad interface, it just wasn't as good as AgileZen.  The AgileZen interface was just better UX design overall.  AgileZen also presents a much better user interface graphical design all together.  It is much closer to what the Kanban Board would look like if it were a physical Kanban Board.  Since one of the HUGE reasons for Kanban is to increase visibility, the fact the design is similar to what a real Kanban Board is actually a pretty big deal. This is an image (click for larger) that shows the two Kanban Boards side by side.  The one on the left is AgileZen and the right is Leankit. Original Entry

    Read the article

  • #altnetseattle - Kanban

    - by GeekAgilistMercenary
    The two main concepts of Kanban is to keep the queues minimum and to maintain visibility. Management/leadership needs to make sure the Kanban Queue doesn’t get starved.  This is key and also very challenging, being the queue needs to be minimal but also can’t get too small during the course of work.  This is to maintain maximum velocity. Phases of the Kanban need to be kept flowing too, bottlenecks need removed ASAP when brought up. Victory Wall – I dig that idea.  Somewhere to look to see the success of the team. The POs work in Rally or other tools for some client management, but it causes issues with the lack of "visibility" – a key fundamental ideal & part of Kanban. One of the big issues is fitting things into a sprint, when Kanban is used with Scrum, but longer sprints are wasteful. Kanban work sizes are of a set size. At this point I got a bit side tracked by the actual conversation and missed out on note taking.  Overall, people doing Kanban and Lean Style Software Development I would say are some of the happiest coders around.  The clean focus, good velocity, sizing, and other approaches that are inferred by Kanban help developers be the rock stars and succeed. This is definitely a topic I will be commenting on a lot more in the near future.

    Read the article

  • Why has extreme programming (XP) gone out of date in favor of Agile, Kanban etc?

    - by Nick Rosencrantz
    I like XP (extreme programming) especially the part where there are 2 programmers at the same screen since often a problem's solution gets closer if only you explain what you're doing and pair programming forces you to explain what your doing. Last 10 years or so, the XP style of working seems to have gone out of date in favor of the working methodologies Agile and/or Kanban. Why? Since XP to me seems a veru good way to work and is a lot about the programming where Agile and Kanban are more about processes.

    Read the article

  • Using a Kanban board per developer

    - by grimus
    I have been trying to get our software department to adopt some kind development process methodolgy. We only have 9 developers, and about as many projects. Currently, we can only be described as chaotic. Or perhaps 'crisis driven development' as I've seen another SO user call it. Using Kanban seems like a it could be a good fit for us. So I've discussed it with everyone else, everyone thought it sounded good. But when we discussed how the board(s) should be arranged, everyone wanted to do one board per person. Now, I've never tried Kanban, or any methodology really, but it feels like having each person managed on their own board would negate the benefits a Kanban process is supposed to provide. This notion makes me sad, and want to say 'ho-hum let's scrap this whole idea.' Do you think implementing a Kanban board per developer can be worthwhile?

    Read the article

  • Learn Lean Software Development and Kanban Systems

    - by Ben Griswold
    I did an in-house presentation on Lean Software Development (LSD) and Kanban Systems this week.  Beyond what I had previously learned from various podcasts, I knew little about either topic prior to compiling my slide deck.  In the process of building my presentation, I learned a ton.  I found the concepts weren’t very difficult to grok; however, I found little detailed information was available online. Hence this post which is merely a list of valuable resources. Principles of Lean Thinking, Mary Poppendieck Lean Software Development, May Poppendieck Lean Programming, Mary Poppendieck Lean Software Development, Wikipedia Implementing Lean Software Thinking: From Concept to Cash, Poppendieck Lean Software Development Overview, Darrell Norton Lean Thinking: Banish Waste and Create Wealth in Your Corporation The Goal: A Process of Ongoing Improvement The Toyota Way Extreme Toyota: Radical Contradictions That Drive Success at the World’s Best Manufacturer Elegant Code Cast 17 – David Laribee on Lean / Kanban Herding Code Episode 42: Scott Bellware on BDD and Lean Development Seven Principles of Lean Software Development, Przemys?aw Bielicki Kanban Boards for Agile Project Management with Zen Author Nate Kohari Herding Code 55: Nate Kohari brings Your Moment of Zen James Shore on Kanban Systems Agile Zen Product Site A Leaner Form of Agile, David Laribee Kanban as Alternative Agile Implementation, Mark Levison Lean Software Development, Dr. Christoph Steindl Glossary of Lean Manufacturing Terms Why Pull? Why Kanban?, Corey Ladas

    Read the article

  • Lean/Kanban *Inside* Software (i.e. WIP-Limits, Reducing Queues and Pull as Programming Techniques)

    - by Christoph
    Thinking about Kanban, I realized that the queuing-theory behind the SW-development-methodology obviously also applies to concurrent software. Now I'm looking for whether this kind of thinking is explicitly applied in some area. A simple example: We usually want to limit the number of threads to avoid cache-thrashing (WIP-Limits). In the paper about the disruptor pattern[1], one statement that I found interesting was that producer/consumers are rarely balanced so when using queues, either consumers wait (queues are empty), or producers produce more than is consumed, resulting in either a full capacity-constrained queue or an unconstrained one blowing up and eating away memory. Both, in lean-speak, is waste, and increases lead-time. Does anybody have examples of WIP-Limits, reducing/eliminating queues, pull or single piece flow being applied in programming? http://disruptor.googlecode.com/files/Disruptor-1.0.pdf

    Read the article

  • kanban scrumish tool(s) to get started

    - by Davide
    After investigating a little bit scrum and kanban, I finally read this answer and decided to start using kanban, picking something from scrum (note that I'm working mostly by myself, and I do have read this question and its answers). Now, my question is: which tool would be best to get started? whiteboard and postit agilezen.com JIRA with greenhopper a spreadsheet (possibly on Google Docs) brightgreenprojects.com Agilo Target Process something else (please specify) Notes about each: I would lean towards the whiteboard, but there are several drawbacks (e.g. cannot make automatic charts, time measurements, metrics, and sometimes I work from home - where I need it most - and it's not convenient to carry :-) I don't want to remember another username/password (I promised to myself to signup only to OpenID-enabled services) My employer has JIRA but my group doesn't use it - I might ask for an account (it shouldn't require another password) and maybe later involve the rest of the group. But I don't know if they are using greenhopper and if it's a big deal installing it. I generally hate spreadsheets maybe overkill? I'd be happy to have a localhost instance, but it could be problematic to give access to the whole group (per network/firewalls) - not a deal-breaker but surely a concern What I'd like to get from this? being more productive tracking how much time I spend in any given task, possibly discussing the issue with my supervisor tracking what "blocks" me most often immediately see where I am compared to my schedule manage in a better way my long todo list (e.g. answering faster to the "what I should do next?" question) Do you have any suggestion? Note on the scrumish tag: read the Henrik Kniberg's PDF. He first introduced the definition of scrumish on page 9.

    Read the article

  • Kanban board plug-in for Trac

    - by kirill_l
    Is there any plug-in/app for presenting/managing tickets from Trac bug tracking system on Kanban board? For example, I want to be able to change the status of Trac tickets by dragging-dropping them accross the board. I tried some standalone tools like AgileZen but but I couldn't find a way to integrate them with Trac.

    Read the article

  • SonicAgile 2.0 with a Real-Time Backlog and Kanban

    - by Stephen.Walther
    I’m excited to announce the launch of SonicAgile 2.0 which is a free Agile Project Management tool.  You can start using it right now (for free) by visiting the following address: http://sonicagile.com/ What’s special about SonicAgile?  SonicAgile supports a real-time backlog and kanban. When you make changes to the backlog or kanban then those changes appear on every browser in real-time. For example, if multiple people open the Kanban in their browser, and you move a card on the backlog from the To Do column to the Done column then the card moves in every browser in real-time. This makes SonicAgile a great tool to use with distributed teams. SonicAgile has all of the features that you need in an Agile Project Management tool including: Real-time Backlog – Prioritize all of your stories using drag-and-drop. Real-time Kanban – Move stories from To Do, In Progress, to Done Burndown Charts – Track the progress of your team as your work burns down over time. Iterations – Group work into iterations (sprints). Tasks – Break long stories into tasks. Acceptance Criteria – Create a checklist of requirements for a story to be done. Agile Estimation – Estimate the amount of work required to complete a story using Points, Shirt Sizes, or Coffee Cup sizes. Time-Tracking – Track how long it takes to complete each story and task. Roadmap – Do release planning by creating epics and organizing the epics into releases. Discussions – Discuss each story or epic by email. Watch the following video for a quick 3 minute introduction: http://sonicagile.com/ Read the following guide for a more in-depth overview of the features included in SonicAgile: http://sonicagile.com/guide-agile-project-management-using-sonicagile/ I’d love to hear your feedback!  Let me know what you think by posting a comment.

    Read the article

  • What is the role of traditional issue tracker when Scrum / Kanban board is used?

    - by Borek
    From a very high level view, to me it seems there are generally 2 types of Project Management tools: Traditional issue trackers like Fogbugz, JIRA, BugZilla, Trac, Redmine etc. Virtual card boards / agile project management tools like Pivotal Tracker, GreenHopper, AgileZen, Trello etc. Sure, they overlap in one way or another, e.g. Pivotal Tracker tasks can be imported to JIRA, GreenHopper itself is implemented on top of JIRA issue base etc. but I think one can still see the difference in orientation between those two types of tools. Traditional issue tracker seems to be used even in companies otherwise doing agile project management. My question is, why do they do that? I also feel that we should use an issue tracker in my company but when I'm thinking about it, I'm not actually sure why should we need it. For example, Trello development seems to be managed by using Trello itself (see this virtual wall) even though they have access to Fogbugz, one of the best issue trackers around. So maybe we don't need traditional issue tracker when we'll be doing 100% of our work in an agile manner using one of the agile PM tools?

    Read the article

  • Livre gratuit à télécharger : Kanban et Scrum, par Henrik Kniberg et Mattias Skarin, traduit en fran

    Bonjour, Une traduction de Kanban and Scrum - making the most of both de Henrik Kniberg et Mattias Skarin publié par InfoQ a été faite bénévolement par Claude Aubry, Frédéric Faure, Antoine Vernois, et Fabrice Aimetti. Vous pouvez donc le télécharger gratuitement sur l'hébergement Developpez.com dédié aux contributions d'Henrik. Prochainement vous pourrez également le consulter entièrement en ligne Et bien sur, un grand merci aux 4 traducteurs pour c...

    Read the article

  • Project Management Techniques (high level)

    - by Sam J
    Our software dev team is currently using kanban for our development lifecycles, and, from the reasonably short experience of a few months, I think it's going quite well (certainly compared to a few months ago when we didn't really have a methodology). Our team, however, is directed to do work defined by project managers (not software project managers, just general business), and they're using the PMBOK methodology. Question is, how does a traditional methodology like PMBOK, Prince2 etc fit with a lean software development methodology like kanban or scrum? Is it just wasting everyone's time as all the requirements are effectively drawn up to start with (although inevitably changed along the way)?

    Read the article

  • Agile and different facet of software development

    - by arjun
    It is said that the Kanban methodology is suited for software maintenance and support areas, whereas Scrum is more suited for new product development. No process or methods are complete. Using the right one will help you succeed, but they will not guarantee success. Which agile approach is best suited for a project which is basically a re-platforming from one technology to another (say from Java to .NET).

    Read the article

  • What electronic scrum/kanban board do you use and recommend for distributed teams?

    - by Derick Bailey
    I have a coworker on a team that is fairly distributed, fairly large (for our company) and wants to take advantage of visual management tools like scrum / kanban boards. Since they are a somewhat distributed team, though, all of the issue management / work management must be done via an electronic tool (we currently use Trac). What issue / work management tools, with a visualization of a scrum / kanban board, do you use for your distributed scrum / kanban teams? would you recommend it, and if so, why?

    Read the article

  • What eletronic scrum/kanban board do you use and recommend for distributed teams?

    - by Derick Bailey
    I have a coworker on a team that is fairly distributed, fairly large (for our company) and wants to take advantage of visual management tools like scrum / kanban boards. Since they are a somewhat distributed team, though, all of the issue management / work management must be done via an electronic tool (we currently use Trac). What issue / work management tools, with a visualization of a scrum / kanban board, do you use for your distributed scrum / kanban teams? would you recommend it, and if so, why? Thanks.

    Read the article

  • How to stop Lean programming becoming Cowboy Coding?

    - by Matt Howells
    My team has been progressively adopting more and more lightweight methodologies, moving from Scrum to Lean/Kanban where there is less and less formal process. At some point we will be back to Cowboy Coding; indeed I fear we may already be on the border line. Where can the line be drawn between a very lightweight Lean and Agile process and anarchy? How will we know when we have crossed the line? And how can we prevent ourselves from crossing the line? The question might also be phrased as, 'what processes cannot be safely eliminated in Lean's drive to eliminate waste'?

    Read the article

  • Topeka Dot Net User Group (DNUG) Meeting – April 6, 2010

    - by Robz / Fervent Coder
    Topeka DNUG is free for anyone to attend! Mark your calendars now! SPEAKER: Troy Tuttle is a self-described pragmatic agilist, and Kanban practitioner, with more than a decade of experience in delivering software in the finance and health industries and as a consultant. He advocates teams improve their performance through pursuit of better practices like continuous integration and automated testing. Troy is the founder of the Kansas City Limited WIP Society and is a speaker at local area groups on team related topics. He currently works as a Project Lead Consultant with AdventureTech Group of Kansas City, KS. TOPIC: Why Kanban? Kanban is receiving a large amount of attention recently. What does it offer compared to other approaches? Answering that question may require you to hit the “reset” button on previously held biases and assumptions. Kanban blends Lean thought with ideas from first generation agile methodologies. To get started with Kanban, we will examine what steps are necessary to establish a transparent, work-limited, pull system. We will highlight the perils of allowing too much work-in-progress and how it affects development performance. Once established, Kanban teams need only a few metrics and tools to monitor their performance and improvement. WHERE: Federal Home Loan Bank Topeka on the Security Benefit Campus – Directions? WHEN: 11:30 AM - 1:00 PM on April 6th, 2010 REGISTER: http://topekadotnet.wufoo.com/forms/topeka-dnug-meeting-attendance/ ADDITIONAL INFO: As always, please sign in and out of FHLBank to help them with their accountability. Please park in the visitors section at the front of the building when you arrive. If  there are no spots in visitors you may park in the overflow lot at the far east end of the facility.  Lunch will be provided and we will have some great door prizes!

    Read the article

1 2 3  | Next Page >