Skip to main content

Home/ Agilesparks/ Group items tagged 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

Creating an Agile Culture to Drive Organizational Change - 1 views

www.borland.com/...creating-an-agile-culture.html

agile enterprise adoption culture

shared by Yuval Yeret on 15 May 09 - Cached
  • It is critical that everyone has the same understanding of, and commitment to, the desired outcome: a business that is reliable through predictable technology processes that deliver business agility. To do this, there needs to be a management commitment to develop a focused, on-going practice around the pursuit of organizational maturity. As part of this, gaps in skills and capabilities should be identified and positive action – training, coaching, process improvement and tools deployment – taken in order to close the gap
  • the work force needs to understand the business drivers for Agility. They need to be challenged to improve their quality, improve their cycle times, to improve the frequency of releases and the value they deliver to the customer. They need to know how these things fit within the bigger picture and why improvement is their responsibility.
  • To change a culture it's important to recognize that every knowledge worker makes decisions and takes actions that affect the performance of the business. The culture in the organization is the reflection of those decisions and actions.
  • ...14 more annotations...
  • all the people understand and internalize the concepts and ideals behind the Agile movement
  • translated into concepts that can be widely applied to the many day-to-day decisions each of them will make
  • internalize and live three principles: making progress with imperfect information; existing in a high trust, high social capital culture; and shortening cycle times. These ideas need to be infused into the workforce at every opportunity.
  • it should spread virally. It can start with just one manager, who educates his immediate direct reports on the concepts and then takes the time to reflect and show how each decision is aligned the principles
  • work-in-progress as a liability rather than an asset.
  • . Every member of the team should be educated to understand it, and to be capable of demonstrating how their decisions and actions are concomitant with it. The Decision Filter is
  • The Agile Decision Filter
  • Delivering quickly can provide immediate value while delay can result in obviated functionality of little value or missing a more lucrative opportunity while completing existing work-in-progress
  • Are we making progress with imperfect information? Or are we trying to be perfect before we start? Does this decision add or maintain trust in our organization and with our partners? Or does it remove trust and breed fear? Are we treating work-in-progress as it if were a liability? Or are we treating it like an asset?
  • the team can start to modify their practices one decision at a time and drive towards a goal of business agility
  • The "transition" to Agile will happen slowly, and supporting the change will require training, coaching and tools – but change will be real and long-lasting.
  • By changing your culture using the simple principles captured in The Agile Decision Filter, teams will adopt Agile. Give it a little time and magic will happen. They will voluntarily change their behaviors and adopt Agile practices. They will behave in a fashion aligned with the principles and values behind The Agile Manifesto. They will not resist because they had a say in the changes, which are tailored specifically to their environment and their needs.
  • this approach may seem less prescriptive and straightforward than an "Agile Change Initiative" project plan. And yes, taking on a management-led Agile Transition Initiative looks faster and cheaper,
  • However, it is all wishful thinking, and the only way to get the payoff is to invest the time and show the courage to lead true Agile change. True Agile change requires you to change the culture. To change the culture, teach all your people how to use the Agile Decision Filter and hold them accountable for every decision they make.
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

From the Agile Transformation Trenches: Borland Agile Assessment 2009 - 1 views

borland.typepad.com/...and-agile-assessment-2009.html

shared by Yuval Yeret on 03 May 09 - Cached
  • We measure progress in business-valued terms such as time-to-value, cost/benefit ratio and customer satisfaction.
  • There is no "score" to this assessment.  It is administered anonymously with results reported in aggregate.  This is a diagnostic tool to help us all reflect on our processes and identify ways to improve.  It cannot measure "improvement" from a previous assessment, only relative importance of potential improvements to our current situation.  
  • inally, this is not a competition.  The results will be most useful in helping you reflect on your current circumstances and establish priorities within your teams on areas of potential growth.
Yuval Yeret

InfoQ: What is Velocity Good For? - 2 views

www.infoq.com/...velocity-value

agile velocity

shared by Yuval Yeret on 09 Jul 09 - Cached
  • Doubling velocity (story points done-done in each sprint) usually means we must improve several things:
  • a clearer definition of done
  • no [known] bugs escape the Sprint
  • ...6 more annotations...
  • we must prioritize the impediments, and keep removing or reducing the top one until velocity is doubled
  • Hint: We might want to prioritize the impediments by how much the removal/reduction will increase velocity. 25% here, 30% there; pretty soon you're talking a real increase in velocity.
  • Hint: Improving quality and reducing technical debt are almost always important keys to seriously increased velocity. Not the only keys, but very important.
  • Velocity is best used for long term planning. I can look at my velocity over several iterations and come up with an average (Preferably a range.) Then I can use that information to say things like: 1) Given the current backlog, how many iterations is it likely to take to complete a given set of stories? 2) How many story points, and by extension what set of prioritized stories, can I deliver by date X (e.g. in time for the trade show?)
  • I am very wary of anyone who suggests increasing velocity is a goal. *They are just estimates*. It is so easy to game. I've seen it happen both consciously and subconsciously with very undesirable effects.
  • The only measure of increased productivity is completed work. Measuring this also has the desirable side effect of encouraging people to break work down into the smallest possible deliverable units.
Yuval Yeret

Challenging Why (not if) Scrum Fails | NetObjectives - 0 views

www.netobjectives.com/...questioning-why-scrum-fails

shared by Yuval Yeret on 22 May 09 - Cached
  • I do believe for Scrum to work beyond the team you need more than Scrum
  • what to add to Scrum making it more effective when it won't readily work
  • lack of team agility is not always the major impediment to Enterprise Agility
  • ...12 more annotations...
  • While starting at the team level with Scrum is often good, you often need to start with the product management team - that is, where product enhancements to be worked on are selected
  • Even when Scrum works at the team level, organizations very often report little impact to the bottom line.  While this is better than nothing (if the teams are happier, that's good), it usually doesn't justify a huge investment
  • in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in.  In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do.
  • These impediments are often not even seen or if they are, are often viewed as "just the way it is."
  • certain Scrum attitudes often makes things worse
  • Scrum does little to let management to know how the team works or what impact management decisions have on the team
  • There is almost a religious zeal that Scrum tells you little of what to do
  • While SoS works well for certain types of work, it does not work well when the different teams have different motivations. 
  • the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn't work wel
  • One needs to pay attention to where to start as well as see how to change the context.  Separating the team from management doesn't help.  Focusing on only the team part of the value stream - giving little guidance both up and downstream of the team also doesn't help.  Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights),
  • look into using Lean as a context for any improvement in your software development organization
  • While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development).  Scrum's rapid ascension probably has more to do with its success in the places it easily fits.  Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.
Yuval Yeret

Company-Wide Business Agility and the Soviets - 0 views

www.borland.com/...any-wide-business-agility.html

agile transformation

shared by Yuval Yeret on 04 Jun 09 - Cached
  • Tom Grant, a Forrester analyst who covers agile and product management, brought early results of his research on business agility to P-Camp. He has divided technology companies into An agile "vanguard" implementing first-wave improvements in their software development models, and Agile "transformation" companies making broad corporate-wide improvements in understanding customers and cross-departmental coordination.
  • "the end of Soviet-style development." He reminded us that Soviet five-year plans had little to do with the reality of hungry Russians and empty store shelves. In the same vein, technology companies with top-down command-and-control waterfalls tend to be unresponsive and overly optimistic. They often lack good market-sensing mechanisms or useful bottoms-up development metrics, so they routinely deliver unexciting products later than planned.
1 - 20 of 51 Next › Last »
Showing 20▼ items per page