Skip to main content

Home/ Agilesparks/ Group items tagged continuous-improvement

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
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

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

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

tips on reviving retrospectives from the retrospectives yahoo group - 0 views

finance.groups.yahoo.com/...1575

agile retrospectives agilesparksblog

shared by Yuval Yeret on 08 Jul 09 - No Cached
  • Has the team made changes that make a difference to them as a result of the retrospective?
  • Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?
  • For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).
  • ...14 more annotations...
  • Try a 'speed retrospective'. How quickly can the team get together and find one good, solid improvement to make? Make it exciting and use a stopwatch. I wouldn't do this all the time, but again, what harm to try it once?
  • How about one retrospective where you set yourselves the challenge of generating actions from the "What did we do well" column? In other words, find an action designed to magnify an existing positive rather than remedy an existing negative.
  • How about a 'Show and Tell' retrospective where every team member comes to the meeting with an action item and its explanation already prepared? The retrospective would really be each person presenting their idea in turn.
  • How about a retrospective wherein you challenge yourselves to come with a new approach to retrospectives that is so exciting that people would skip other work activities to attend?
  • I find it very important to revisit the outcome of the past retrospective and celebrate the things the team had been able to do differently.
  • The major thing is to make the changes visible and memorizable for everyone and not assuming that people remember what they decided on in the last retro.
  • Another thing is that I would invite team members to take turns in facilitating the retro. So not always the same person runs the retro (this typically also changes the format and techniques a bit).
  • - Heartbeat Retrospective (google for Boris Gloger)
  • - Temperature Reading
  • - Team Radar Chart
  • - Our project / team / product ship - draw a ship on a flip chart, ask the team what moved the ship forward, what blocked it
  • Just to add a totally different direction: I've made good experiences with having a *long* retrospective every few months. The short retrospectives are great to see the trees and optimize the daily work. A two or even three day retrospective helps the team to step back and watch the forrest instead.
  • It is important to get at least one item done every sprint. If you do the retro, but don't implement any of the actions, this is a tremendous demotivator. Better one thing finished that you can celebrate than 5 unfinished things in the queue.
  • Variety is the spice of life, so some variation is essential to keep the freshnees. Change the moderator, do technical focus once, then organisational, then "improving the fun factor", then go back to a general retro.
Yuval Yeret

Scrum Log Jeff Sutherland: The Managers Role in Scrum - 1 views

jeffsutherland.com/...managers-role-in-scrum.html

agileblog agile management managers

shared by Yuval Yeret on 01 Jun 09 - Cached
  • managers handle 'external stuff' to the team
  • ontract negotiations and procurement.
  • he role that a line manager plays in an employee's personal and professional development, often in the form of coaching or assisting in HR-related issues
  • ...11 more annotations...
  • - (1) Provides organizational vision- (2) Removes impediments- (3) Assists with individual development- (4) Challenges team beyond mediocrity while respecting team boundaries- Helps individuals without sucking the responsibility out of the team- Balances observer and contributor roles- Gives individuals tools to be a great team member- Coaches teams through conflict resolution- Advocates for continuous improvement for teams and the organization at large- Buys things for the team (manages budget)- Provides the right environment- Manages portfolio of projects
  • 1. Providing organizational vision: Often teams flail because there is no vision 'from on high'. Having this vision is important for team members to be able to relate their daily actions.
  • manager's role in this process to remove escalated impediments from the team(s).
  • provide strategic vision, business strategy, and resources
  • 3. Assists with individual development: We all have managers who mentor us in professional and sometimes personal growth. We felt that this is an important role for the manager to continue to play. Not all scrummasters have the authority or expertise to help in this regard.
  • a manager role would be like a 'ScrumMaster on steriods'- a person whose job it is to remove all escalated impediments for the team, take care of external stuff to the team, lead the team by challenging it, and assists direct reports with individual development and other HR-related challenges.
  • CMMI Level 5 Requirement 2.4.10 Review the activities, status, and results of the Agile Methods with higher level management and resolve issues (GP2.10)
  • ensure that higher level management has appropriate visibility into the project activities.
  • The principle of self-managed teams would say "let them be; let them find their own way." A principle of leadership, however, is to challenge teams. We discussed the fine line between challenging teams and taking away their ability to self-manage.
  • Jens Ostergaard
    • Yuval Yeret
      Yuval Yeret on 01 Jun 09
       
      my CST...
Yuval Yeret

James Shore: The Art of Agile Development: Simple Design - 0 views

www.jamesshore.com/...simple_design.html

james shore art development

shared by Yuval Yeret on 13 Jan 15 - No Cached
  • Simple Design AudienceProgrammers Our design is easy to modify and maintain
  • Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. —Antoine de Saint-Exupéry Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction. —Albert Einstein
  • When writing code, agile developers often stop to ask themselves, "What is the simplest thing that could possibly work?" They seem to be obssessed with simplicity. Rather than anticipating changes and providing extensibility hooks and plug-in points, they create a simple design that anticipates as little as possible, as cleanly as possible. Unintuitively, this results in designs that are ready for any change, anticipated or not.
  • ...10 more annotations...
  • I don't think XP and patterns are conflicting. It's how you use patterns. The XP guys have patterns in their toolbox, it's just that they refactor to the patterns once they need the flexibility
  • You Aren't Gonna Need It (YAGNI) This pithy XP saying sums up an important aspect of simple design: avoid speculative coding. Whenever you're tempted to add something to your design, ask yourself if it supports the stories and features you're currently delivering. If not, well... you aren't gonna need it. Your design could change. Your customers' minds could change.
  • We do this because excess code makes change difficult. Speculative design, added to make specific changes easy, often turns out to be wrong in some way, which actually makes changes more difficult. It's usually easier to add to a design than to fix a design that's wrong. The incorrect design has code that depends on it, sometimes locking bad decisions in place.
  • Once and Only Once
  • avoid duplication. "Once and only once" is the Extreme Programming phrase. The authors of The Pragmatic Programmer [Hunt & Thomas] use "don't repeat yourself," or the DRY principle.
  • Self-Documenting Code Simplicity is in the eye of the beholder. It doesn't matter much if you think the design is simple; if the rest of your team or future maintainers of your software find it too complicated, then it is.
  • What if we know we're going to need a feature? Shouldn't we put in a design hook for it? In XP, the plan can change every week. Unless you're implementing the feature that very week, don't put the hook in. The plan could change, leaving you stuck with unneeded code.
  • Results When you create simple designs, you avoid adding support for any features other than the ones you're working on in the current iteration. You finish work more quickly as a result. When you use simple design well, your design supports arbitrary changes easily. Although new features might require a lot of new code, changes to existing code are localized and straightforward.
  • Simple design requires continuous improvement through refactoring and incremental design and architecture. Without it, your design will fail to evolve with your requirements. Don't use simple design as an excuse for poor design. Simplicity requires careful thought. As the Einstein quote at the beginning of this section says, it's a lot easier to create complex designs than simple ones. Don't pretend "simple" means "fastest" or "easiest.
  • Until recently, the accepted best practice in design followed the advice Erich Gamma now disavows: "The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements, and in designing your systems so they can evolve accordingly."
1 - 10 of 10
Showing 20▼ items per page