Skip to main content

Home/ Agilesparks/ Group items tagged business

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

The Product Owner in the Agile Enterprise - 0 views

www.agilejournal.com/...-owner-in-the-agile-enterprise

agile product_owner embedded-agile-list

shared by Yuval Yeret on 07 May 09 - Cached
  • Responsibilities Vary by Software Business TypeSince the business mission, organization, operating methods, roles, titles and responsibilities differ dramatically across industry segments, it follows that the patterns of agile adoption vary across these segments as well
  • Information Systems/Information Technology (IS/IT) -teams of teams who develop software to operate the business; accounting, CRM, internal networks, sales force automation and the like. Customers are primarily internal to the enterprise.
  • Embedded Systems (embedded) - teams of teams who develop software that runs on computers embedded in other devices - cell phones, electronic braking systems, industrial controls and the like. Customers may be either internal or external to the enterprise.
  • ...17 more annotations...
  • Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.
  • So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.
  • ultimate user (mobile device user) is fairly far removed from the major technologies
  • Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:
  • Embedded Systems Example - Symbian Software Limited
  • Clearly, the development of a mobile phone operating system is a highly technical endeavor
  • mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV
  • the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.
  • All our POs come from engineering teams and are senior engineers with product or customer experience.
  • one PO to two team mapping typically, rarely 3 teams, sometimes 1
  • IS/IT Examples
  • role/title of the Business Systems Analyst
  • is often a reasonably good fit for the Product Owner role.
  • In the larger IT shop, I have also seen the role filled by Project Managers
  • In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.
  • In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business
  • Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests
Yuval Yeret

10 Questions to Ask Your Customer for Written or Video Testimonials - 0 views

www.sensiblemarketing.com/...-written-or-video-testimonials

testimonials customer questions

shared by Yuval Yeret on 14 Mar 16 - No Cached
  • How did you get involved with our company? What was the reason that you chose us? 
  • Tell me what your experience has been with our products/services? (Ask for the customer's experience and wisdom.)
  • Can you think of a word or phrase that best describes your relationship with us? Why that particular word or phrase?
  • ...2 more annotations...
  • How has working with us changed the way your company does business?
  • Why would you recommend us to someone else? (This is the key part of the testimonial.) If someone called you and said "Why should I do business with XYZ company", what would you tell them?
  • Yuval Yeret on 14 Mar 16
     
    "Questions to Ask Your Customer for a Written or Video Testimonial Give me a one-minute history of your career (or your success, or your business). (Get them relaxed and comfortable. Everyone loves talking about themselves.) How did you get involved with our company? What was the reason that you chose us?  Was price more important that delivery, service, and quality? (This question gets to the value of the products/services you provide.) Tell me what your experience has been with our products/services? (Ask for the customer's experience and wisdom.) Can you think of a word or phrase that best describes your relationship with us? Why that particular word or phrase? How has working with us changed the way your company does business? Have you had our competitors knock on your door? If so, what did you tell them? Why would you recommend us to someone else? (This is the key part of the testimonial.) If someone called you and said "Why should I do business with XYZ company", what would you tell them?"
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

Tailor your Message To Gain Support for your Agile Initiative | Enabling Agility - 0 views

www.enagility.com/r-your-message-to-gain-support

tailor agility agile adoption transformation

shared by Yuval Yeret on 21 May 09 - Cached
  • Connect Agile’s Benefits to your Company’s Priorities
  • aying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change.  You could implement Agile, but you could also try Six Sigma or Lean.  Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.
  • ur last two releases have looked like me-too updates, where we are just barely keeping up with our competitors
  • ...21 more annotations...
  • f they don’t see a meaningful update from us, at least once a quarter, we’re going to get kicked out of the game.  We’ve all acknowledged that as we’ve gotten bigger, our processes have become more cumbersome and now is the time to do something about it.  Agile will give us the ability to regain that rapid pace of delivering innovations to market that we were know for in our early days.”
  • We’ve been losing market share
  • If you can refer to a specific business issue and show the linkage, you are much more likely to get a receptive audience.  Here’s an example.
  • The focus isn’t on Agile, its on business, as it should be.
  • Use Focused Messages for Key Individuals or Groups
  • certain volume of people who are enrolled in the idea of Agile before you’ll see adoption start to accelerate,
  • People have specific needs in their role and they want to understand how Agile will affect and benefit them directly.  
  • Developers, on the other hand, probably wants to know if they will have interesting work, the opportunity to learn new things and the ability to make an impact on the company’s products.
  • a QA manager is probably interested in hearing how Agile helps enrich the QA profession.
  • The CFO, developer and QA manager have different roles in the organization and their needs are different.  If you want to enlist their support, be sure you know who you are talking to and what they value.
  • The easiest way to find out what interests someone is to ask them.  When you meet, leave plenty of time for talk.  Motoring through a well-rehearsed Agile presentation usually doesn’t work.  A lot of times I’ll have slides with me, but they are a backdrop for the conversation.  I’ll refer to slides when it helps move the conversation along, but otherwise don’t use them.  You might want to forget slides altogether and just draw things on a whiteboard as necessary.  This technique is particularly useful with an individual or a small group.  
  • Take it One Step Further: Collect Data to Gain Insight
  • you’ll be most effective tailoring your message if you invest some time conducting data through a series of structured interviews. 
  • First, you’ll need a small set of questions prepared for the interviews.  Here are some examples. What is working with our current methodology? What’s not working with our current methodology? How do you think Agile would help our organization? What concerns do you have about Agile?
  • Interview a wide range of people: developers, testers, business analysts, managers, product managers, senior management, project managers and someone from finance. 
  • When you conduct the interviews, it is good to have one interviewer who has the primary responsibility for talking and the other person who has the primary job of taking notes.  You can switch off roles each interview so no one person gets stuck in either role.  Here’s how I typically start off.  
  • stories that people tell about the organization and make sure you write them down
  • I put all of the information we’d gathered into a mind-mapping program (Mindjet) and grouped like things together.
  • Make sure you keep interesting stories intact.  Specifics will help you make your cases
  • When there’s numerical data, people engage with a presentation in an entirely different way than they do when there are stories.  I find stories more effective, but do what works for you.
  • As an Agile evangelist, you job is to get Agile deployed effectively.  Along the way there are many people will be willing to go out of their way to help if you effectively speak to their interests and concerns.
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.
Yuval Yeret

Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-... - 0 views

agileproductdesign.com/...kanban_over_simplified.html

lean kanban

shared by Yuval Yeret on 03 Jun 09 - Cached
  • It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.
  • It’s easier to plan with smaller stories. With big stories — stories that might take weeks for a developer to implement — it becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks. It seems that only a couple stories fit — and there’s often room for half a story — but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.
  • Shrinking stories forces earlier elaboration and decision-making. Where product owners could write their stories fairly generally and consider many of the details later, now breaking them down into smaller stories forces more thinking earlier in a planning lifecycle.
  • ...36 more annotations...
  • Managing little stories forces us to keep better track of how they fit together. Product owners are often asked to break down stories to a level where a single story becomes meaningless. To keep track of what’s meaningful to them and other stakeholders, they often need to keep track of bigger items such as the features of the product and how many stories contribute to building up that feature.
  • The result of these herniated time-box activities is a cycle that’s actually 3-4 times longer than our time-box. To get work done, we’ll use a time-box to elaborate stories, one to develop them, another to more thoroughly test them, and if there are bugs, possibly another to fix them.
  • Anyone who’s attended an Agile planning meeting knows they can often last about an hour longer than you can stand it
  • It’s difficult to fit thorough validation of the story into a short time-box as well. So, often testing slips into the time-box after. Which leaves the nasty problem of what to do with bugs� which often get piped into a subsequent time-box.
  • During an ideal Agile time-box we’ll have frequent discussions between developers, testers, and those on a product owner team — like business analysts, user experience people, and business people. We’ll do this to understand what we need to build and describe what we’ll do to validate the story was really done. When time-boxes are short, there’s less time for this conversation. It’s common to move many of the conversations to detail the story and describe acceptance to the time-box before so we can be ready to really get moving with development when the time-box starts.
  • As time-boxes shrink those on the product owner team and testers find themselves in a constant mode of getting ready for a next time-box and evaluating past time-boxes
  • “Kan” means visual, and “ban” means card or board.
  • Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)
  • work long hours, attend lots of meetings, and seem to have less time to be available to help developers with the current time-box. Since their focus is on a future or past time-box, questions about this time-box seem like interruptions. Collaboration decreases and tensions increase. Their work load is heavy, bumpy, not smooth or even.
  • Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team.
  • In Kanban development: time-boxed development is out stories are larger and fewer estimation is optional or out completely velocity is replaced by cycle time
  • Exactly what’s left of Agile if we get rid of time-boxes, change the meaning of stories, and stop measuring velocity. And, exactly what do car doors and Kanban cards have to do with software development? Don’t get hung up on process. Remember, agile development isn’t a process.
  • These columns aren’t set. You should discuss with your team the phases that stories go through to be completed. Some organization may use columns for writing documentation, or preparing customer service people to support the feature in production.
  • You might have a column where business analysts spend time tracking down technical details that developers need to understand to write code.
  • The top is used for stories currently in progress in that phase. The bottom is the buffer. When work for that phase of the story is completed, it moves from “in progress” to the “buffer” where it’ll wait to be pulled into the next phase.
  • When we set limits for work in progress, we’ll set a total number for the process step that includes both “in process” and the “finished buffer” for that process step.
  • Stories must be minimal marketable features
  • To be marketable the feature needs to be large enough to be useful — probably larger than the teeny stories that take a couple days to build and seem to be best practice in Agile development today. A MMF may take weeks to build. But the important thing isn’t how long it takes to build, but that it be understandable and valuable to those who’ll receive it. To identify a MMF some folks ask the question “Would I announce it in my company’s product blog?” If it’s too tiny to mention, then it’s not a MMF.
  • To be lean, we’ll limit the number of stories we allow onto the board. A common formula is to add up all the members of the team in all roles and divide by two. All roles includes developers, analysts, user interfaced designers, testers, deployment people — anyone immediately responsible for getting features to market. For example, if team members total 20, we might limit the number of MMF-style stories on the board to 10.
  • Today developers have finished a story, and s they walk to the Kanban board to move it out of development, they notice their single buffer slot is full — and the “testing in progress” column is filled to its limit. What now? The developers talk to the testers. “We’re really struggling to keep up here. It’ll be till tomorrow morning before we can get some of these stories moved out.” “Hmm�” says a developer “Can we help test?” “Of course you can!” says the tester. “With your help we can get these cleared out by the end of the day.“ The tester grins “I just don’t want you validating a story you implemented.”
  • For the limits of the story process steps, the limit is often half the number of people that can perform the work for that phase of development. For instance if you have 6 developers, you might limit the development in progress column to 3. Now, this will force developers to work together on stories. I do find in practice that this may not work out for all teams — so I often see limits that equal the number of developers (or those that can perform the process step) or often 1.5 * the number of people in a role. Of course if you do this, it’ll raise the overall work in progress — and as you might expect, items will take longer to finish.
  • When a column in a Kanban board is full, we know that group is at capacity. We also know that if this keeps happening that that process step is likely where a bottleneck is.
  • If you’ve ever waited in line for the Pirates of the Caribbean in Disneyland you might remember signs along the way that say “Your wait time from here is 30 minutes” — something like that. Now you can post your own wait times on your Kanban board. At the bottom of your story queue post the average cycle time with wait time. It’ll say something like “Your wait time for a story here is approximately 18 days.” At the top of the queue post the average working cycle time. It might say “your wait time from here is 14 days.”
  • But, since there’s no development time-box in Kanban development, we’ll measure story-by-story how long they took to complete — the “cycle time” of the story.
  • When you place focus on how quickly you can get functionality done, and have the ability to measure just that, then the estimates don’t much matter. In fact, many using a Kanban approach have simply stopped estimating at all. Yes story sizes vary, but being able to give a wait time plus or minus a few days is sufficient for many organizations’ concerns.
  • Some do still estimate stories. Then use those estimates in conjunction with cycle time. Using a spreadsheet we can calculate the average cycle time for stories with a given estimate. If you do this, consider placing a handy chart next to your Kanban board showing estimate in one column, and wait times in adjacent columns. With this you’re answering the real question stakeholders are asking for when they get estimates: “when am I going to see this functionality in the software?”
  • The only difference is the cycles aren’t used to plan and commit to stories any longer.
  • If I know that during three week time period there where 15 working days and that 5 developers worked the entire time, that’s 75 developer days. Knowing that lets me calculate the average number of developer days per story: 3.4 (75/22) — Which is darn close to pi — which makes me believe it has to be right. ;-) This number, 3.4, is what XP practitioners referred to as load factor.
  • Evaluation cycles, not development time-boxes
  • If your stakeholders are like mine, they don’t want to know when they’re going to get this functionality, the want to know when they’re going to get all this functionality. I find that if I place stories into a spreadsheet with start and end dates, and calculate cycle time, if I select an arbitrary time period — say a two or three week time period — I can see how many stories where completed during this time period. For instance I might see the team finished 22 stories in 3 weeks — that’s about 7.3 stories per week. Given a backlog of 100 stories I can reasonably infer that it’ll take between 13 and 14 weeks (100/7.3). That’s yesterday’s weather for Kanban — at least the way I calculate it.
  • The daily standup or daily scrum meeting occurs as normal, but now it occurs in front of the Kanban board. Instead of the regular meeting ritual of checking in with each person to find out what they worked on yesterday and will work on today, the discussion revolves around the Kanban board and what will likely move on and off the board today, where “traffic” seems the heaviest, and what we could do to clear bottlenecks.
  • Reflect every few weeks
  • Lean practices help teams increase throughput. They don’t make developers type faster, rather they draw attention to bottlenecks that slow things down, help you see them and respond to them quicker. Using a Kanban board lets you easily visualize work in progress across different roles and lets you see when someone is taking on too much work simultaneously.
  • Demonstrate every few weeks
  • A task board as it’s commonly used in an agile approach can give you the visualization too. But, widening the task board to separate testing from development from acceptance or other process steps helps me better visualize where things are clogging up — helps me better diagnose problems. And, setting hard limits for process steps and respecting them really makes me deal with the problem in a way that dropping a pile of stories into a sprint or iteration didn’t. But, maybe it’s just me who’s lazy and avoids dealing with tough problems. I’m sure you’d never run into a situation where you and your team let lots of finished development work pile up waiting to be tested.
  • There’s no one as zealous as the newly converted There’s a lot of folks pretty excited about Kanban out there. I am too. Sometimes that zeal takes the form of telling people practicing common agile time-boxed development that they’re wrong. But, I guess I’m crusty enough to know that there’s lots of right ways to succeed and anyone who believes they’ve found the best ways is likely wrong. Don’t let those voicing opinions strongly for, or against, Kanban approaches stop you for digging in deeper and understanding the ideas behind it.
  • Yuval Yeret on 03 Jun 09
     
    one of the best articles about Kanban and its relation to Agile I've encountered so far - focusing on Feature development (not maintenance)
Yuval Yeret

James Shore: Value Velocity: A Better Productivity Metric? - 0 views

jamesshore.com/...etter-Productivity-Metric.html

agile roi productivity

shared by Yuval Yeret on 24 Jun 09 - Cached
  • *Please note that I'm specifically talking about productivity. Velocity is a great tool for estimating and planning and I'm not trying to change that. It's just not a good measure of productivity.
  • rather than asking your business experts to measure business value after delivery (difficult!), have them estimate it beforehand. Every story (or feature--keep reading) gets an estimate before it's scheduled. At the end of each iteration, add up the value estimates for the stories you completed in that iteration. This is your "value velocity."
  • And rather than reflecting the hours programmers work, as cost velocity does, value velocity actually reflects productivity. Remember, productivity equals output/time. Value estimates are a much better indication of output than cost estimates are.
  • ...7 more annotations...
  • It's like traditional velocity, except it's based on your customers' estimates of value rather than your programmers' estimates of cost.
  • Although value velocity isn't perfect, a team with consistent value estimates would be able to graph their value velocity over time and see how their productivity changes. This would allow them to experiment with new techniques ("Let's switch pairs every 90 minutes! Now once a week!") and see how they affect productivity. If balanced with actual measures of value and some sort of defect counting, this could be a powerful tool.
  • stories don't always have value on their own.
  • just estimate and score features rather than stories.
  • Another option would be to pro-rate each feature's estimate across all of the stories required to deliver it.
  • some types of stories don't provide value in the traditional way. What's the value of fixing a nasty crash bug?
  • Third, value velocity is just as vulnerable to gaming as cost velocity is... perhaps more so. I'm not sure how to prevent this.
Yuval Yeret

Getting business value out of Agile Retrospectives - Ben Linders - 0 views

www.benlinders.com/...ue-out-of-agile-retrospectives

twitterfavs forsite

shared by Yuval Yeret on 23 Mar 14 - No Cached
  • Yuval Yeret on 23 Mar 14
     
    @yuvalyeret To assess your retrospectives, here's some inspiration http://t.co/7D1QtvArfg http://t.co/ubX8w6q0sC http://t.co/cxhuhglbkl
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.
1 - 20 of 43 Next › Last »
Showing 20▼ items per page