Skip to main content

Home/ Agilesparks/ Group items tagged agile-risk-management

Rss Feed Group items tagged

Yuval Yeret

CIO Perspectives: A Conversation on Agile Transformation, Part 2 - 0 views

  • Part 2
  • The thinking is that IT is mission-critical, so let's not change things without giving it a lot of thought and a lot of consideration
  • The really hard part is around the people transformation - getting developers to work side-by-side with testers and users is a completely foreign concept.
  • ...8 more annotations...
  • The reason there's been so much turnover of CIOs in the last ten years is because the end users – the CEOs, the CFOs and the division heads – are unhappy with the results. When IT professionals realize this, and realize that something like Agile gives them the opportunity to create better value for their businesses, then they're going to be a lot more willing to adopt it. I hope that development organizations are starting to see around that corner.
  • We WANT to go Agile. How do we overcome the skepticism at the CXO level?"
  • My recommendation would be "try it." Agile doesn't equal risk, but changing development methods does equal some risk
  • t can be a big deal to say: "I'm going to change our development methodology." It makes people sit up and want to dive into deep detail before getting on board. The question comes in the form of the old development methodology: "Let me see the high level plan and what the change will be in the deliverables and methodology over the next two years." This is exactly what you're trying to avoid by going to an Agile method.
  • try Agile on a few small projects, measure the results, talk to users about their satisfaction, and then readdress
  • nitiate the shift in the most change-prone areas first, and then work it backwards through the rest of the organization
  • It doesn't happen everywhere at all times, and it doesn't work in all areas. It's good to recognize that up front – that software development projects adapt to this easily, but an infrastructure project would have challenges with this approach. So, select a few areas that would naturally lend themselves to Agile, such as application development, gradually introduce it to these areas that need it most, and then measure results.
  • Again I'd say: "Try it." Agile transition is absolutely about organizational change. To win executive support we need to speak in terms of risk management, measurement and the bottom line.
Yuval Yeret

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

  • 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

Why agile transitions initiatives might fail : Jeffrey Palermo (.com) - 1 views

  • The executive makes a “vendor” or external “coach” responsible for the transition If you have handled the first risk and have defined success and success metrics, you likely will not find a vendor who will base his payment on your metrics.  After all, the metrics likely call for less project failure rate, faster response times, etc.  You probably can’t measure these things in less than a year if you really want objective metrics and not one optimized for short-term results at the expense of the longer term.  A vendor might want: # of people trained % of teams using an “agile” project management tool # of teams with an embedded “agile champion” # of successful iterations It is really easy to accomplish the above metrics and still not make any material change in the organization.  I have worked with a client that did something similar to the above.  Most of the teams starting using some new Scrummy project management web application for project tracking.  They declared that monthly status meetings were now iterations.  They declared a member of the team to be the Scrummaster (and sent that person to training).  Overall, the same organizational problems persisted.  Vendors cannot produce real change in an organization unless the organizations executive leadership alters the culture in a meaningful way.
Yuval Yeret

Agile Game Development: The Project Manager Role - 0 views

  • The Project Manager works with the Product Owner to insure that cost is always a consideration when evaluating the Product Backlog.
  • "Super Scrum Master"
  • Tracking costs, especially for production
  • ...6 more annotations...
  • Facilitate the Product Owner's role (backlog maintenance and meetings)
  • Among the Project Manager's responsibilities:
    • Yuval Yeret
       
      sounds like what some organizations will call "Program Manager"
  • Tracking project risk
  • The Project Manager on a Scrum project has to be a Scrum expert and evangelist.
  • As each Scrum team on the project evolves their practices, the Project Manager will insure that they are continuing to work effectively with the other teams
  • One example of this would be the application of Test Driven Development and similar practices to build stability. It doesn't make sense for some teams to use TDD while others don't. The PM would have to step in and work with all the teams to insure that practices won't interfere or cancel each other out.
1 - 13 of 13
Showing 20 items per page