Skip to main content

Home/ Agilesparks/ Group items tagged integration

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

http://studios.thoughtworks.com/2007/5/10/continuous-integration-in-the-enterprise-with... - 0 views

studios.thoughtworks.com/...-enterprise-with-cruisecontrol

continuous_integration

shared by Yuval Yeret on 19 Jan 17 - Cached
  • One of the developers had checked in some code that failed the regression tests. The application, on which the company had spent considerable time, money and effort, was now in an uncertain state. It wasn't behaving as expected. In the past, this type of bug usually wasn't discovered for months. Usually, it wasn't discovered until the System Integration Testing cycle got underway. For this project, that wasn't scheduled for another 6 months.
  • In the past, this bug would have lingered in the code for 6 months before anyone even realized it was a problem
  • . The light had gone off only 6 minutes after the code had been committed. Notice: not 6 months...but 6 minutes!
  • ...1 more annotation...
  • I told them I just saved them $12,535! They looked around to figure out how. The reason I was there was simple. Earlier that year, those same IT managers had performed a series of calculations to estimate how much it cost the department each time a bug made its way out of development, into SIT, into User Acceptance Testing, or all the way into production. For this IT shop, one bug into SIT cost them $12,605 (and you can imagine how much a bug into production would cost.)
Yuval Yeret

Continuous Integration - 0 views

martinfowler.com/...continuousIntegration.html

integration continuousintegration development agile eng-practices-list CI-list

shared by Yuval Yeret on 30 Mar 14 - Cached
  • On the whole I think the greatest and most wide ranging benefit of Continuous Integration is reduced risk. My mind still floats back to that early software project I mentioned in my first paragraph. There they were at the end (they hoped) of a long project, yet with no real idea of how long it would be before they were done.
Yuval Yeret

Alistair.Cockburn.us | Are iterations hazardous to your project? - 0 views

alistair.cockburn.us/s+hazardous+to+your+project%3f

shared by Yuval Yeret on 20 Jun 09 - Cached
  • Simply using iterations, user stories and velocity doesn’t mean your project is agile – or on the way to success.
  • why “iterations” may be hazardous to your project: ‘’Danger grows when the results of the iteration are not directly linked to delivering the product to the end user.’’ Without that linkage, iteration results hang in the air
  • What gets in the way is that the project is set up as a pipeline, with programming put somewhere in the middle of the pipeline. In this project setup, there is really nothing the programmers can do to show how their work connects to deliveries, because there are work stations before and after theirs. All they can report is that “some new code is integrated into the code base.” They are doing incremental development but not agile development.
  • ...6 more annotations...
  • magine a project team of between fifteen and four hundred people. There are user representatives, analysts, programmers, database designers, and testers, arranged in a pipeline. The user analysts talk to the users, and then to the analysts, who write down user stories. The analysts write lots of notes on each user story, since it will be a full iteration or two before any programmer will pick up the user story. The notes are between one and ten pages long. Eventually, a programmer picks up a user story along with the supplemental details, code them up in an iteration, integrate them into the growing code base, and mark their velocity. In the same or a later iteration the database designers do the same. Eventually the integration test team comes along, runs tests on the whole thing, and feeds bug reports back into the programmers’ work queues. The users or project sponsors may see the outcome every few months if they are lucky.
  • The repair is simple: connect every activity to a release or delivery to real users (delivering to even one real user makes a difference). Evaluate the team’s work based on how often they deliver to real users and how long it takes a new requirement to reach the users. Replace the fuss around iterations with fuss around deliveries.
  • Break the pipeline, lengthen the iterations, lose the machismo, deliver the project.
  • here is no mechanism in the standard agile language that warns about this loss of touch. The currently standard language consists of ‘’iterations, user stories, ‘’and’’ velocity’’. By a perverse relationship between them, it is possible to equally shrink iteration length and story size, with velocity scaling accordingly. Thus, a team can feel as though it is become more agile, when in reality it is simply becoming more cut off from its user base and the feedback it needs to succeed.
  • Collocate the requirements gatherer, the database designer, the programmer, the tester. Lengthen the iteration period to one month. Give the requirements gatherer a week’s head start on the features coming up, but otherwise arrange that all of them are working on the same feature set in the same month.
  • As an afterthought, if your new iteration length is a month, you can still run one-week planning windows to make sure you don’t get off track during the month.
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

Agile PMO Role - 0 views

www.gantthead.com/...articlesPrint.cfm

agile pmo

shared by Yuval Yeret on 20 Jul 09 - Cached
  • Institute an agile transition team, and have the agile PMO play a significant role on that team. If you are starting on the journey, establishing an agile transition team can be a critical factor in your success. The agile transition team plans and implements the strategy for the organization’s agile transition (using a backlog, iterations, planning meetings, retrospectives and, in general, responding to change) This group monitors and communicates results throughout the organization, and is responsible for removing organizational level impediments. The PMO representative can act as ScrumMaster for the agile transition team. Members should be leaders representing different departments and functions that are impacted by the agile transition. For example, having leaders from development, QA, product development and the PMO is an excellent practice.
  • Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy. As part of optimizing the whole, it is important for there to be a big picture view across products and features. In general, product managers are tasked with defining, prioritizing and communicating the vision and features for their products. When you have a program that encompasses multiple products with multiple product owners and project teams, keeping everything in line with the corporate vision can sometimes be overlooked.   Unlike the Scrum of Scrums--which is tactical, i.e. focused on execution--the Meta Scrum is focused on the strategic planning and decisions guiding the program or programs as a whole. Establishing a Meta Scrum with the PMO representative acting as ScrumMaster to plan and facilitate meetings (as well as reporting and tracking decisions and action items) can add significant value in having a program able to rapidly respond to change while staying true to the corporate strategy and objectives.
  • I like using story points to establish the velocity of individual teams. From a program point of view, however, story points are difficult to use across multiple teams. The nut there is that one team’s story point is not equivalent to another team’s story point. To crack that nut, I use agileEVM to “normalize” to standard project management metrics like the Cost Performance Index and the Schedule Performance Index, as well as the Estimate At Complete in integrated dollars. These metrics can be aggregated across teams to establish progress against the plan for the entire program.
  • ...1 more annotation...
  • Establish an agile CoachingCenter. It is important from an organizational perspective to continue to provide coaching and training to agile teams. Team development and facilitation needs continue after the initial shift to agile methods is completed. In addition, new team members are hired, new practices discovered and implemented. Establishing an agile coaching center of excellence can meet this need.   In order to be successful, the center needs to be a legitimate organization with an assigned budget, staff and objectives. The center can be a located within the agile PMO. The center can develop and manage a central agile library, produce various lunch ‘n’ learns and other programs to infuse agile values and knowledge across the organization, and provide proficient, independent facilitators to teams for various retrospectives and other needs. In addition, the center can help the team gather metrics on their agility and health so that the team can take action if the decide to.
Yuval Yeret

EE Times - Using agile methods in medical device development - 0 views

www.eetimes.com/document.asp

medical agile case study

shared by Yuval Yeret on 08 Dec 14 - No Cached
  • FDA and other regulatory agencies fundamentally want to see that your product has safety in mind. To do so, they require complete traceability through the hardware and software. There is even a fairly new standard, IEC 62304, adopted worldwide that is wholly focused on software traceability from requirements through architecture to tests.
  • Medical devices companies are going primarily agile to respond to change and effectively manage technical complexity by collaboratively building solutions with their partners and customers to ultimately deliver what the customer wants before the competition does.
  • demo the new functionality created after each iteration to your customers, using web-based meets. Using these tools enables you to get immediate feedback from your customers throughout the project. Continuous customer feedback reduces the risk of building the wrong solution. The fact is in most cases you can’t make the release cycle more frequent since it includes giving tests to regulatory agencies. This is a tedious process that makes sure the device is safe. Doing the whole release cycle more frequently can be way too time consuming.
  • ...3 more annotations...
  • ou could also give a version to select customers as long as it will not be directly used for care or diagnosis on current patients. The idea there is the customer gets the current iteration in house for say a blood analyzer. They could load it with real patient data and test out the new functionality as long as it is not used to diagnose an existing patient, since it has not gone through regulatory
  • agile development has gotten so popular in medical device companies that the AAMI (Association of Medical Instrumentation) is currently working on new guidance for mapping agile to a medical standard called IEC 62304.
  • In conclusion, agile development works and is being used in medical device development. The issue is you need to have a good toolchain that allows for complete traceability across the entire lifecycle in order to comply with standards. It is also very important to integrate and test frequently. This, in turn, leads to the need for build automation. With all of this in place, agile development for medical devices becomes much easier to make work.
Yuval Yeret

How Is Kanban Different From Other Approaches? « AvailAgility - 1 views

availagility.wordpress.com/...ifferent-from-other-approaches

kanban

shared by Yuval Yeret on 17 Jun 09 - Cached
  • Scrum places more emphasis on the project management practices. Kanban, places its emphasis on business and value flow practices.
  • its all the same elephant, but each approach has a different view of it. At the end of the day, its having the most appropriate elephant for any given context that is most important.
  • Kanban can be differentiated by identifying its Primary and Corollary Practices.
  • ...6 more annotations...
  • Map the Value Stream
  • Visualise the Work.
  • Limit Work in Progress.
  • A Kanban approach will explicitly limit work in progress. This is distinct from managing work in progress through the use if time-boxes
  • Establish a Cadence.
  • A Kanban team will almost certainly use Corollary Practices which may be considered Primary in another process. For example, a high performance Kanban team will inevitably use technical practices from XP, such as TDD and Continuous Integration.
1 - 14 of 14
Showing 20▼ items per page