James Shore: The Art of Agile Development: Incremental Design and Architecture - 1 views
-
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...
Managing Risk on Agile Projects with the Risk Burndown Chart - 1 views
Agile Risk Management | Bart Vermijlen - 1 views
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...
Risk Kanban Board - Zsolt Fabók - 1 views
Multi-Voting / Dot Voting - 0 views
-
A good guide to follow is 20% of the total number of items. So, in the case of 30 risks being prioritized, each voting team member would receive 6 votes to assign across the population of risks.
Engineering Higher Quality Through Agile Testing Practices The Agile Coach - 1 views
-
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.
Continuous Integration - 0 views
-
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.
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...
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...
Saint Sebastian and Scaling Agile | The IT Risk Manager - 0 views
Alistair.Cockburn.us | Agile contracts - 1 views
-
Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.
-
Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.
-
Bob Martin’s idea Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point. This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.” I have not seen that model in action myself, but several people have written in recommending it.
- ...2 more annotations...
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.
Executives and Top-Down Transformations | The IT Risk Manager - 0 views
1 - 19 of 19
Showing 20▼ items per page