Skip to main content

Home/ Agilesparks/ Group items tagged continuous

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

The Kanban Method - Fixing Continuous Improvement - AgileIL12 by Yuval Yeret on Prezi - 0 views

prezi.com/...ntinuous-improvement-agileil12

kanban conference talk improvement journey yuvalyeret Continuous Improvement prezi improvement-list agile-change-management-list

shared by Yuval Yeret on 22 Mar 14 - No Cached
  • Yuval Yeret on 22 Mar 14
     
    "The Kanban Method - Fixing Continuous Improvement - AgileIL12 How Kanban provides a more sustainable and viable approach to Continuous Improvement by Yuval Yeret on 1 October 2012
Yuval Yeret

LSSC12: The Improvement Journey - Yuval Yeret on Vimeo - 0 views

vimeo.com/43222643

kanban conference talk vimeo improvement journey yuvalyeret video Continuous Improvement improvement-list agile-change-management-list

shared by Yuval Yeret on 22 Mar 14 - No Cached
  • Yuval Yeret on 22 Mar 14
     
    "This presentation was given at the Lean Software and Systems Conference 2012 (LSSC12). Lean/Agile is not just about delivering early and often, it is even more importantly about continuously adapting the way we work towards an improved capability of delivery. Yet how many of us have worked in a continuously improving organization? How many of us have seen one in real life? It's hard to keep management interested in Improvement for very long, making Continuous Improvement a holy grail of sorts. As Lean/Kanban practitioners we believe the only sustainable way to improve is via evolutionary emerging change. But if we the organization is not interested in pursuing it, we have a big problem. Through some challenging situations from real client work we will see a few patterns that fail and a few patterns that show more promise for energizing improvement. We will also look at improvement pace and how to apply kanban approaches to make the improvement more sustainable. We will also explore some local cultural aspects that might affect the drive (or lack of) towards improvement, and how to deal with them, with some interesting insights about the Israeli culture…"
Yuval Yeret

James Shore: The Art of Agile Development: Incremental Design and Architecture - 1 views

www.jamesshore.com/...incremental_design.html

eng-practices-list james shore evolutionary design agilearchitecture

shared by Yuval Yeret on 10 Dec 14 - No Cached
  • when you first create a design element—whether it's a new method, a new class, or a new architecture—be completely specific. Create a simple design that solves only the problem you face at the moment, no matter how easy it may seem to solve more general problems
  • Waiting to create abstractions will enable you to create designs that are simple and powerful.
  • The second time you work with a design element, modify the design to make it more general—but only general enough to solve the two problems it needs to solve. Next, review the design and make improvements. Simplify and clarify the code. The third time you work with a design element, generalize it further—but again, just enough to solve the three problems at hand. A small tweak to the design is usually enough. It will be pretty general at this point. Again, review the design, simplify, and clarify. Continue this pattern. By the fourth or fifth time you work with a design element—be it a method, a class, or something bigger—you'll typically find that its abstraction is perfect for your needs. Best of all, because you allowed practical needs to drive your design, it will be simple yet powerful.
  • ...12 more annotations...
  • This is difficult! Experienced programmers think in abstractions. In fact, the ability to think in abstractions is often a sign of a good programmer. Coding for one specific scenario will seem strange, even unprofessional.
  • Continuous Design Incremental design initially creates every design element—method, class, namespace, or even architecture—to solve a specific problem. Additional customer requests guide the incremental evolution of the design. This requires continuous attention to the design, albeit at different time-scales. Methods evolve in minutes; architectures evolve over months. No matter what level of design you're looking at, the design tends to improve in bursts. Typically, you'll implement code into the existing design for several cycles, making minor changes as you go. Then something will give you an idea for a new design approach, requiring a series of refactorings to support it. [Evans] calls this a breakthrough (see Figure). Breakthroughs happen at all levels of the design, from methods to architectures.
  • Don't let design discussions turn into long, drawn-out disagreements. Follow the ten-minute rule: if you disagree on a design direction for ten minutes, try one and see how it works in practice. If you have a particularly strong disagreement, split up and try both as spike solutions. Nothing clarifies a design issue like working code.
  • Risk-Driven Architecture Architecture may seem too essential not to design up front. Some problems do seem too expensive to solve incrementally, but I've found that nearly everything is easy to change if you eliminate duplication and embrace simplicity. Common thought is that distributed processing, persistence, internationalization, security, and transaction structure are so complex that you must consider them from the start of your project. I disagree; I've dealt with all of them incrementally [Shore 2004a]. Two issues that remain difficult to change are choice of programming language and platform. I wouldn't want to make those decisions incrementally!
    • Yuval Yeret
      Yuval Yeret on 12 Jan 15
       
      Possible exercise - Try to come up with various things that are risky to YAGNI. And then order them according to level of risk. Use the examples here to seed the list
  • Limit your efforts to improving your existing design
  • To apply risk-driven architecture, consider what it is about your design that concerns you and eliminate duplication around those concepts
  • Your power lies in your ability to chooose which refactorings to work on. Although it would be inappropriate to implement features your customers haven't asked for, you can direct your refactoring efforts towards reducing risk. Anything that improves the current design is okay—so choose improvements that also reduce future risk.
  • design is so important in XP that we do it all the time
  • Don't try to use incremental design without a commitment to continuous daily improvement (in XP terms, merciless refactoring.) This requires self-discipline and a strong desire for high-quality code from at least one team member. Because nobody can do that all the time, pair programming, collective code ownership, energized work, and slack are important support mechanisms.
  • Test-driven development is also important for incremental design. Its explicit refactoring step, repeated every few minutes, gives pairs continual opportunities to stop and make design improvements. Pair programming helps in this area, too, by making sure that half of the team's programmers—as navigators—always have an opportunity to consider design improvements.
  • Alternatives If you are uncomfortable with XP's approach to incremental design, you can hedge your bets by combining it with up-front design. Start with an up-front design stage and then commit completely to XP-style incremental design. Although it will delay the start of your first iteration (and may require some up-front requirements work, too), this approach has the advantage of providing a safety net without incurring too much risk.
Yuval Yeret

http://studios.thoughtworks.com/2007/5/10/continuous-integration-in-the-enterprise-with... - 0 views

studios.thoughtworks.com/...-enterprise-with-cruisecontrol

continuous_integration

shared by Yuval Yeret on 19 Jan 17 - Cached
  • One of the developers had checked in some code that failed the regression tests. The application, on which the company had spent considerable time, money and effort, was now in an uncertain state. It wasn't behaving as expected. In the past, this type of bug usually wasn't discovered for months. Usually, it wasn't discovered until the System Integration Testing cycle got underway. For this project, that wasn't scheduled for another 6 months.
  • In the past, this bug would have lingered in the code for 6 months before anyone even realized it was a problem
  • . The light had gone off only 6 minutes after the code had been committed. Notice: not 6 months...but 6 minutes!
  • ...1 more annotation...
  • I told them I just saved them $12,535! They looked around to figure out how. The reason I was there was simple. Earlier that year, those same IT managers had performed a series of calculations to estimate how much it cost the department each time a bug made its way out of development, into SIT, into User Acceptance Testing, or all the way into production. For this IT shop, one bug into SIT cost them $12,605 (and you can imagine how much a bug into production would cost.)
Yuval Yeret

Continuous Integration - 0 views

martinfowler.com/...continuousIntegration.html

integration continuousintegration development agile eng-practices-list CI-list

shared by Yuval Yeret on 30 Mar 14 - Cached
  • On the whole I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk. My mind still floats back to that early software project I mentioned in my first paragraph. There they were at the end (they hoped) of a long project, yet with no real idea of how long it would be before they were done.
Elad Amit

Continuous Deployment at IMVU: Doing the impossible fifty times a day. « Timo... - 0 views

timothyfitz.wordpress.com/...e-impossible-fifty-times-a-day

shared by Elad Amit on 31 May 09 - Cached
  • Elad Amit on 31 May 09
     
    Great
Yuval Yeret

Agile PMO Role - 0 views

www.gantthead.com/...articlesPrint.cfm

agile pmo

shared by Yuval Yeret on 20 Jul 09 - Cached
  • Institute an agile transition team, and have the agile PMO play a significant role on that team. If you are starting on the journey, establishing an agile transition team can be a critical factor in your success. The agile transition team plans and implements the strategy for the organization’s agile transition (using a backlog, iterations, planning meetings, retrospectives and, in general, responding to change) This group monitors and communicates results throughout the organization, and is responsible for removing organizational level impediments. The PMO representative can act as ScrumMaster for the agile transition team. Members should be leaders representing different departments and functions that are impacted by the agile transition. For example, having leaders from development, QA, product development and the PMO is an excellent practice.
  • Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy. As part of optimizing the whole, it is important for there to be a big picture view across products and features. In general, product managers are tasked with defining, prioritizing and communicating the vision and features for their products. When you have a program that encompasses multiple products with multiple product owners and project teams, keeping everything in line with the corporate vision can sometimes be overlooked.   Unlike the Scrum of Scrums--which is tactical, i.e. focused on execution--the Meta Scrum is focused on the strategic planning and decisions guiding the program or programs as a whole. Establishing a Meta Scrum with the PMO representative acting as ScrumMaster to plan and facilitate meetings (as well as reporting and tracking decisions and action items) can add significant value in having a program able to rapidly respond to change while staying true to the corporate strategy and objectives.
  • I like using story points to establish the velocity of individual teams. From a program point of view, however, story points are difficult to use across multiple teams. The nut there is that one team’s story point is not equivalent to another team’s story point. To crack that nut, I use agileEVM to “normalize” to standard project management metrics like the Cost Performance Index and the Schedule Performance Index, as well as the Estimate At Complete in integrated dollars. These metrics can be aggregated across teams to establish progress against the plan for the entire program.
  • ...1 more annotation...
  • Establish an agile CoachingCenter. It is important from an organizational perspective to continue to provide coaching and training to agile teams. Team development and facilitation needs continue after the initial shift to agile methods is completed. In addition, new team members are hired, new practices discovered and implemented. Establishing an agile coaching center of excellence can meet this need.   In order to be successful, the center needs to be a legitimate organization with an assigned budget, staff and objectives. The center can be a located within the agile PMO. The center can develop and manage a central agile library, produce various lunch ‘n’ learns and other programs to infuse agile values and knowledge across the organization, and provide proficient, independent facilitators to teams for various retrospectives and other needs. In addition, the center can help the team gather metrics on their agility and health so that the team can take action if the decide to.
1 - 20 of 44 Next › Last »
Showing 20▼ items per page