Skip to main content

Home/ Agilesparks/ Group items tagged Improvement

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

InfoQ: Ensuring Success for Self Organizing Teams - 0 views

www.infoq.com/...lf-organization-success-factor

agile management self_org

shared by Yuval Yeret on 08 Jul 09 - Cached
  • Helicopter Managers – who step in too soon to rescue thereby depriving the team to think and solve problems together.
  • Absentee Managers – who would not step in at all irrespective of whether the team has all the necessary skills to tackle the problem.
  • If the team has sufficient skills to solve the problem then give them space else ask questions to help them get unstuck. This would help in building the skills eventually.
  • ...7 more annotations...
  • When time is not of the essence give the team time to work the issue. This would improve the team feeling and collaboration.
  • If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time.
  • Tolerate mistakes and allow time for learning – management should not jump in at the first problem. They should allow the team to learn from their mistakes and take corrective action on their own.
  • Clearly define the boundaries – Without this the team is lost on how much they can manage themselves and when should they invoke management help. Without the definition of boundaries, teams err on side of caution and do not take any decision without seeking permission.
  • Keep the team challenged, yet not frustrated- The manager should be aware of the team’s skill level and limitations. He should be able to provide the team with enough challenges to keep them in a state of learning and growth.
  • emphasis on the balanced involvement of management with the team
  • It is important for the managers to be aware of the skill level of the team to step in or stay back at the right moment and act as a catalyst for the team to reach a state of self organization
Yuval Yeret

Agile Resources: Velocity | VersionOne - 0 views

www.versionone.com/...Velocity.asp

scrum velocity

shared by Yuval Yeret on 16 Jun 09 - Cached
  • Does maximum velocity mean maximum productivity? Absolutely not. In an attempt to maximize velocity, a team may in fact achieve the opposite. If asked to maximize velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize refactoring, or many other key benefits of the various Agile development practices. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact. The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
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."
Yuval Yeret

Is Design Dead? - 0 views

www.martinfowler.com/...designDead.html

eng-practices-list

shared by Yuval Yeret on 10 Dec 14 - Cached
  • In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on
  • the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming. So it's inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn't gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There's usually a quicker fix and time pressure. Hence entropy (again).
  • One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won't help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard. Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can't be prevented, however careful your requirements engineering process.
  • ...6 more annotations...
  • The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire.
  • XP's advice is that you not build flexible components and frameworks for the first case that needs that functionality. Let these structures grow as they are needed. If I want a Money class today that handles addition but not multiplication then I build only addition into the Money class. Even if I'm sure I'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, I'll still leave it till that next iteration.
  • You don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to add it because it increases the cost of modification even if it costs nothing to put in. However you can only sensibly behave this way when you are using XP, or a similar technique that lowers the cost of change.
  • My advice to XPers using patterns would be Invest time in learning about patterns Concentrate on when to apply the pattern (not too early) Concentrate on how to implement the pattern in its simplest form first, then add complexity later. If you put a pattern in, and later realize that it isn't pulling its weight - don't be afraid to take it out again.
  • begin by assessing what the likely architecture is. If you see a large amount of data with multiple users, go ahead and use a database from day 1. If you see complex business logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the side of simplicity. Also be ready to simplify your architecture as soon as you see that part of the architecture isn't adding anything.
  • XP design looks for the following skills A constant desire to keep code as clear and simple as possible Refactoring skills so you can confidently make improvements whenever you see the need. A good knowledge of patterns: not just the solutions but also appreciating when to use them and how to evolve into them. Designing with an eye to future changes, knowing that decisions taken now will have to be changed in the future. Knowing how to communicate the design to the people who need to understand it, using code, diagrams and above all: conversation.
‹ Previous 21 - 40 of 51 Next ›
Showing 20▼ items per page