Skip to main content

Home/ Agilesparks/ Group items tagged quality

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

Engineering Higher Quality Through Agile Testing Practices The Agile Coach - 1 views

www.atlassian.com/testing

agile-testing-list

shared by Yuval Yeret on 06 Mar 17 - No Cached
  • Maintaining quality involves a blend of exploratory and automated testing. As new features are developed, exploratory testing ensures that new code meets the quality standard in a broader sense than automated tests alone. This includes ease of use, pleasing visual design, and overall usefulness of the feature in addition to the robust protections against regressions that automated testing provides. 
  • Exploratory testing is a risk-based, critical thinking approach to testing that enables the person testing to use their knowledge of risks, implementation details, and the customers' needs.
  • On our development teams, QA team members pair with developers in exploratory testing, a valuable practice during development for fending off more serious bugs. Much like code review, we’ve seen testing knowledge transfer across the development team because of this. When developers become better testers, better code is delivered the first time.
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

How Google Sold Its Engineers on Management - 0 views

hbr.org/...ld-its-engineers-on-management

last-materials

shared by Yuval Yeret on 16 Mar 16 - No Cached
  • A good manager: 1. Is a good coach 2. Empowers the team and does not micromanage (See the sidebar “How Google Defines One Key Behavior”) 3. Expresses interest in and concern for team members’ success and personal well-being 4. Is productive and results-oriented 5. Is a good communicator—listens and shares information 6. Helps with career development 7. Has a clear vision and strategy for the team 8. Has key technical skills that help him or her advise the team
  • Employees with high-scoring bosses consistently reported greater satisfaction in multiple areas, including innovation, work-life balance, and career development
  • high-scoring managers saw less turnover on their teams than the others did—and retention was related more strongly to manager quality than to seniority, performance, tenure, or promotions
  • ...1 more annotation...
  • The key behaviors primarily describe leaders of small and medium-sized groups and teams and are especially relevant to first- and second-level managers. They involve developing and motivating direct reports, as well as communicating strategy and eliminating roadblocks—all vital activities that people tend to overlook in the press of their day-to-day responsibilities.
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

From the Agile Transformation Trenches: Culture Change with Pigs, not Chickens - 0 views

borland.typepad.com/...ge-with-pigs-not-chickens.html

Agile transition agilesparksblog

shared by Yuval Yeret on 07 Jul 09 - Cached
  • Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).
  • Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong
  • Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.
  • ...3 more annotations...
  • Providing initial training is simply not enough. When the pressure is on, the temptation to return to previous ways of doing things is often too strong to resist. If technical leads are to work for you, they need on-going support and coaching, and a means by which they can support each other.  Good external coaches (expert chickens?) can help here.
  • Let the technical leads continue working on their projects. Some fail at the final hurdle by doing 1-3 above and then assigning or scheduling the technical leads to coach other projects, effectively turning them from pigs into chickens.
  • To summarize, if you can produce a change in the behavior of the lead pigs, the other pigs will, by definition, follow. However, pigs will not follow chickens for long because chickens are simply not pigs.
  • Yuval Yeret on 07 Jul 09
     
    Last month David Anderson wrote a two-part article on why agile transformation initiatives fail. David's suggestion to concentrate on cultural change reminded me of one of my favorite bits on process initiatives. From Peter Coad's book, Java Modeling in Color...
Yuval Yeret

Agile Product Manager in the Enterprise (5): Responsibility 3 - Maintain the ... - 0 views

scalingsoftwareagility.wordpress.com/...3-maintain-the-product-roadmap

agile product_owner product_management

shared by Yuval Yeret on 18 Jun 09 - Cached
  • The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set.
  • While it is a simple thing mechanically to represent the Roadmap, figuring out the content for anything beyond the next release is another matter entirely. The topic of what else the team plans to ship and when can be a fascinating and contentious topic in agile
  • the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process.
  • ...5 more annotations...
  • The dates and themes for the next release are fixed. The features are prioritized and variable.
  • The teams can commit only to the features in the next upcoming release. Releases beyond the next, represent only a best estimate.
  • The Roadmap, then, is a “plan of intent” and is subject to change as development facts, business context and customer needs change. With respect to the upcoming release, perhaps the most important guidance is this:
  • Even though the team has committed to the objectives and we have agreed that the feature set cannot be guaranteed, it is a reasonable expectation that the agile teams will: 1) meet the date 2) accomplish the theme 3) deliver most of the features, and certainly the highest priority ones, with the requisite quality.
  • Anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!
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

Ideal Training for Enterprise-Scale Agility? « Scaling Software Agility - 0 views

scalingsoftwareagility.wordpress.com/...g-for-enterprise-scale-agility

shared by Yuval Yeret on 04 Jun 09 - Cached
  • training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach
  • for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal
  • all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise)
  • ...11 more annotations...
  • an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master
  • All other executives and managers are invited to attend an overview course on scaling software agility
  • Agile for Teams –Essential, team-based training in a two day workshop
  • philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum)
  • Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.
  • Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.
  • The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.
  • Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.
  • Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders. Part I – overview of agility highlighting lessons learned from the most common and effective agile methods Part II – seven team best practices of agility that natively scale to the enterprise level Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility
  • The team member doesn’t need a CSM course, but he does need to know how to work in an agile environment.
  • what are the engineering practices need to support agile development? I’ve found that if developers only have their existing tools and practices, then they will continue to specify and develop waterfall-style within the sprints.
Yuval Yeret

GE Healthcare Goes Agile | Dr Dobb's - 0 views

www.drdobbs.com/...228300298

medical agile case study

shared by Yuval Yeret on 08 Dec 14 - No Cached
  • we operate in a highly regulated environment so there are a number of additional quality and regulatory steps that must be completed before we can accept a "user story"— that scenario written in the business language of the user that captures what he or she wants to achieve. Therefore, our "definition of done" — that is, the list of activities that add value to the product such as unit tests, code coverage, and code reviews — turned out to be lengthy.
  • Yuval Yeret on 08 Dec 14
     
    "Modify: It's OK to use a hybrid approach to agile. GE Imaging Solutions needed more up-front planning and post-sprint testing, for example. "
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

Permanent Link to Feature Flow - Increasing velocity using Kanban - 1 views

blog.xebia.com/...feature-flow-1

lean kanban

shared by Yuval Yeret on 03 Jun 09 - Cached
  • team that had some problems getting their process right
  • their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.
  • one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.
  • ...9 more annotations...
  • existing solution to this problem was to lower the expected velocity each sprint, so the next sprint would be on-time. But at the end of next sprint, the same problem occurred, so the velocity was going down sprint after sprint.
  • pressure of the rest of the organisation for the team to keep up their tempo. This pressure from both sides was crushing morale.
  • The way this team reacted to pressure was to work harder. Most people would have 2 or 3 tasks in progress at the same time. When a developer would finish a task, the testers were too busy testing something else, so they could give the developer direct feedback. When the tester found an issue with a new feature, the developers were already working on something else, so the tester had to wait. Simply put, there was too much focus on working long and hard, not on cooperation and the stuff that actually matters: features.
  • most dysfunctional behaviour comes from the system people are in
  • biggest struggle of this team: pressure & predictability.
  • Most Scrum masters challenge the team to reach the same (or higher) velocity each sprint. This pressure should give a team focus to perform at its best. However, it can also go haywire if the team doesn't deliver. No focus, no pride, no happy customer
  • retrospectives were dismal and planning meetings were a huge burden. The teams' productivity dropped in the days after the sprint, finding new courage to start the next one. Because they had an ineffective work-process, the only outcome of each sprint was to lower the expected velocity, to make sure we would be predictable. Estimation and predictability are only a means to an end and since they were getting in the way of fixing the root cause (and were bringing down the team's spirit) I opted to cut out the planning sessions and sprint deadlines.
  • first change we made was to set a limit of 8 tasks on the 'in progress' column
  • We spent 3 weeks bringing the numbers of open tasks from 21 to 8, without picking up any new work. Of course the team struggled with this new limit. They were used to pick up new work whenever they were blocked somehow, this wasn't allowed any more
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.
1 - 19 of 19
Showing 20▼ items per page