You used to practice them, but then got sloppy.
Or you never really learned to practice them that well before the need to scale was pressed upon you, and now things are growing up and out too quickly to go back and shore up the details.
How do I know this?
I’m just playing the odds that your organization probably falls into that very large group that is struggling to realize the potential of Agile. And I’m considering what I observe all too frequently to be at the root of the struggle.
We all know what we have to do if we want to get in shape, right? Eat better, eat less, and exercise regularly. Simple. So why does the fitness industry rake in tens of billions of dollars annually, while the incidence of obesity and diseases related to lack of fitness keep increasing?
Want to build a financial nest egg? Save and invest more, and consume less, of course. Again, very straightforward, but current research indicates that 76% of Americans are living paycheck to paycheck. Why?
For both of the above, the answer is, more often than not a) the delusion that “the normal rules don’t apply to my situation”, and/or b) a lack of discipline.
Ineffective Agile adoptions, including enterprise-scale transformations, can be traced to these same two causes. In fact, this applies to most things that we human beings don’t follow through on.
So why am I pointing out something so obvious and so universal?
Because I don’t want you to fail.
I don’t want you to run out and buy the Agile equivalent of a Treadmaster 9000 and a “Get Rich Tomorrow” home study course, only to find yourself sick and broke a year from now.
Is your organization holding onto collaboration-killing and throughput-throttling processes, based on the rationale that your business domain or product or technology mix is more complex than that of everybody else who is practicing Agile?
Is it shaving the sharp corners off the parts of Agile that are uncomfortable, either leaving gaps or replacing what was removed with something softer and more accommodating of the status quo?
True, successful Agile enterprises are continuously inspecting and tweaking how they do things. That’s how they get better. But they are tweaking the application of the fundamentals, not the fundamentals themselves.
Even “seasoned” Agile organizations plateau, and then seek out some advanced Agile concept or technique that is guaranteed to take them to the “next level”. But there is none.
No professional sports team’s coach says, at a post-loss press conference, “Well, we were just one or two trick plays away from winning this.” No, what they actually say is, “We didn’t execute on the fundamentals, and it cost us the game.”
The secret to Agile success is that there IS no secret. Success comes through relentless improvement in the application of a few fundamental concepts and values. Your situation isn’t the rare exception.
Yes, this can be challenging, especially when the impediments that need to be addressed are rooted high-up in the enterprise. If it was easy, every organization would be wildly successful, and lots of Agile consultants I know would be running Tilt-a-Whirls at carnivals all over this great country of ours.
But that doesn’t mean it isn’t worth the effort. If you want to succeed, you don’t really have a choice.
I’m invariably surprised how often I get contacted by project management organizations, who want to guest post on my blog, or engage me in some other way to help promote their tools and techniques. Even after twenty years of Scrum in our industry, where the project manager role is noticeably missing, there is somehow a perception that a scrum master and a project manager are the same role. Or that there is still a place for project managers in an agile process. There isn’t. Here, verbatim, is a recent exchange with a tool vendor. Names have been changed to protect the misguided:
My name is John Smith and I represent a team of devs called PM Tool Makers. We build advanced project management software for people with skill and expertise—like your audience. [That’s you, dear reader]
I’m currently preparing a Slideshare presentation on Project Management with 25 - 50 quotes from top influencers in the industry. As you may know, online presentations are currently one of the biggest (and fastest) means to reach great deals of people and Slideshare is no exception here.
I’d really appreciate if you could provide us with one quote of yours that people interested in Project Management could benefit from.The presentation will be branded and you can see it below the link and you also see it in attachment
Looking forward to hearing from you - we’d love to have you included.
I appreciate being noticed, of course, but I usually get the sense that these guys are crawling the agile blogs and hitting on agilists indiscriminately. Kind of like the lonely guy at a night club who thinks maybe he’ll just get lucky tonight. Anyway, I responded:
Thanks for writing. It’s no secret that I don’t have much respect for the discipline of project management—in fact I’ve often written in opposition to it. I believe projects need to be guided, not managed, and that guidance best comes from the teams building the software and the users who use it. I find the role of project manager to be somewhat unnecessary overhead—at best a plug for a hole that people are not effectively stepping up to fill for themselves, usually due to autonomy and empowerment issues with the organizational system in which they work.
Management (of all kinds) is a twentieth century invention. Prior to that we had mentors, master craftsman, visionaries to guide us. I’d like to see a revival of that model.
So, I’m not really the best person to offer you a quote. But here’s something, anyway:
Don’t manage projects. Instead guide teams to manage their own work, and to collaborate with their users. Let go of control. Listen to the voices of the people doing the work. Embrace uncertainty. Ultimately, create an environment where your job becomes superfluous.
Probably not the kind of thing you are seeking :)
Best of luck with your presentation, and your product.
I rather liked the quote. John Smith did not.
Thank you for your quote, but necessarily—yes, is not the kind of I am seeking.
Thanks for your message and good luck!
My job, as I see it, is not to perpetuate the myth that project management is a useful discipline, but rather to challenge that old assumption. At the same time I believe I have a responsibility to socialize a different way of working to those good folk who find themselves in a dying profession. Others have different ideas.
Today is a great day to share some killer tips on how to get the best out of one’s creative potential. These tips would be of special help to digital creative individuals, that is, to anyone, who thinks for a living as they look at a screen. So, whether you are a graphic artist struggling for that elusive touch that would make a corporate identity unique, or a UX designer who wants to put together an intuitive interface, or a product owner looking to figure out what goes next in a product, or a project manager looking to facilitate a team’s performance, or a software developer crafting a piece of code, look no further. This article is your philosopher’s stone for achieving top results.
So, friends, lend me your ears. To turn on this magical power of brilliant insights, one just needs to do these three simple things day in day out.
1. Wherever possible, spend the bulk of your most productive time, preferably in the morning, when your brain is fresh, doing a research online as to how others have done this thing that you’re working on at the moment. If you’re a graphic artist, make sure you not only dig out all possible images or ideas that can be replicated, but remember to throw all those links with images at the other fellow designers in your team. Not only will this help strangle their creative edge ensure that all the industry-accepted standards are followed, but they won’t need to spend any more effort on inventing original concepts. Leave no stone unturned. You need to chase each and every clue. For strategic decisions, make the list of step-by-step routines copied from how others addressed the same challenge. You will never do anything valuable if you fail to follow the proven routines that other people have followed many times before.
2. The second magic success ingredient is to expose the drafts of your work, or to have your incentives for strategic decisions bullied discussed by as many people as one can possibly get. Facebook is an ideal space for that. Remember to be consistent in sharing the in-progress sketches or ideas with strangers, who don’t know you personally and who are completely unaware of the particular context you’re working in. They’d shoot their comments, wasting your time making their invaluable contribution to shaping up this great idea, or a graphic, or a piece of code you’re currently working on. Consistency is the key here. The more exhausted you get filtering out the rare grains of sensibility from the avalanche of clueless comments, the closer you’re to what you’re looking for. The logic here would be the same as on the picture below. One is more likely to build a snowman with plenty of snow, picking out those special unretarded pieces with care.
3. Finally, there goes the trickiest part. Once you’ve let out your finished and polished brainchild to the outer world, work to secure the right attitude to external criticism within yourself. You absolutely need to master the skill of proving your worth based on each and every comment received from your network of personal and professional contacts. The smartest way to accomplish this would be to build a model that would transform the bites of criticism to a numeric value. You’d need to set a certain plank for yourself with this model. Once this value gets below this plank, you need to work harder on the points 1) and 2).
Repeat this cycle forever, and you will sleep serenely, like a baby, enjoying the bliss of reaping harvest from all your hard work.
Em is a senior manager in Information Management. She is a certified Scaled Agile Framework Program Consultant (SPC) and an active member of the Agile community. She frequently speaks about her experiences with Scaling Agile and Agile Data Warehousing at conferences across Australia and the United States.
As mentioned in a prior post, the idea for the EDW Agile Release Train came from reading +Dean Leffingwell‘s Scaling Software Agility. A couple of months after reading the book, there was a restructure and I found myself leading the technology team that I has previously been a customer of. I was eager to pitch the idea of forming an Agile Release Train to my new team, so I arranged a series of workshops with the key leaders across the group.
From these workshops I hoped to achieve shared understanding and agreement on the shape of our future organisation. We kicked off with +Mark Richards sharing what he had learnt about Agile Release Trains from Dean’s Lean Agile Enterprise Leadership Workshop. We also provided everyone with the details of Dean’s more recent book, Agile Software Requirements. Over the remaining workshops we debated various organisational models, operating principles and approaches to getting started until we landed on a majority consensus on the way forward. With our vision agreed it was all hands on deck to get ready for our first release planning (PSI) workshop tentatively scheduled to happen in about 6 weeks.
As the day of our first release planning event grew closer, I noticed that there were some blank faces among my extended leadership team when I referred to various aspects of what we needed to do. My heart sank as I asked the team, “Who has read the book?“. A couple of hands were raised. “Who has finished the book?“. Only one hand (and yes he still works with me!). “Who doesn’t own the book?“. At least four or five hands were sheepishly raised. “OK” I said “Change of plan. We are all going to buy the book. If you cannot afford the book, let me know and I will arrange a book for you. Then we are going to read the book together. We are going to form a book club!” As Deming said, “without theory there is no learning”.
For the next 3 months I met with my extended leadership team for an hour a week. Each week one member of the team lead a discussion on a chapter or two. We would discuss the concepts covered, how they might apply to our situation and agreed on the ideas we wanted to implement. Book club was compulsory and if one team member had something more important to do then book club was rescheduled. Shared understating and agreement was paramount if we were going to be successful. Visitors to the EDW Release Train are often shocked when they hear that I called a mandatory weekly meeting to read a book. I am always quick to remind them that no one would hesitate to call a “business” meeting, so why wouldn’t we want to make time for a meeting focused on learning ways to improve our “business”.
While the “Leffingwell Book Club” (as it was fondly referred to) created the shared understanding that I was eager to achieve, there were some unexpected but positive side effects. First, more book clubs spun up. Our Scrum Masters started with Coaching Agile Teams, our Technical Leads readAgile Analytics, the Test Leads read Agile Testing and one of the feature teams chose to readLean Software Development: An Agile Toolkit. Second, the foundations of what would become our Leadership Continuous Improvement Team emerged as we created a kanban wall to track all the ideas we wanted to implement.
The third and most amazing side effect of the book club was how it enabled the formation of a team. My extended leadership team, was made up of various leaders from the 3 groups that had been merged to create my new organisation. Dean’s book gave us safe material to debate (no pun intended!). No one needed to be worried about hurting someone else’s feelings when offering an opinion on the material.
Today reading is a huge part of our learning culture. Who is reading what is a constant topic of conversation. When people visit us for “tours” we find our book club wall is one of the most photographed and talked about aspects of the EDW Agile Release Train. Some of our visitors have even been inspired to launched their own book clubs – and not just the agile folk! To quote Dr. Seuss, “The more you read, the more things you will know. The more you learn, the more places you’ll go.”For a list of books that have inspired us check out our virtual book club wall. This post first appeared on Em’s blog on October 13, 2013.
When the day to travel arrived, you reset the odometer, set up the GPS and off you went. However, the job of planning wasn’t complete. There might be detours along the way. Frequent glances at the odometer or GPS might inform you that you are ahead or behind schedule. Also, the map and GPS aren’t enough. You monitor your speedometer from time-to-time and constantly look out the windshield and at the mirrors in case another driver does something unexpected.
We use all these different measures and methods to maintain a plan and respond to change for something as predictable as driving. We need similar tools for the far more complex and uncertain endeavor of making a game!
Figure 1 - Planning Onions for Driving and Games
The figure above shows “the planning onion”, which represents the different layers of planning frequency. The inner layers of the onion are the more frequent inspection tools/cycles, while the outer layers encompass tools applied less frequently.
Layers of Planning
Let’s examine the layers of planning from the inside out using the driving example for comparison with how a Scrum-developed game would plan:
- Daily - The team will meet every day in a daily Scrum to discuss the progress and issues which are affecting their Sprint goal. This includes conversations about bugs, impediments, dependencies, or merely points about the quality of the game. This is like looking out the windshield of the car during your trip.
- Sprint - The team, product owner and domain experts forecast what is possible to accomplish in the next one to three weeks. The duration of the sprint largely depends on how much certainty the team has with the work and how long the stakeholders can go without seeing something. A team will forecast and track the work in any way they want for the sprint. Some teams use hours, others days, while some teams will come up with their own units. This compares to using the speedometer in your car to measure you velocity.
- Release - The team, stakeholders, marketing and leads identify stretch goals for the game that they hope will be demonstrated in a “shippable build” at the end of the release. Product owners might alter these goals during the release as quality, cost and true velocity emerges. Forecasting and tracking during a release is usually done using metrics that size the features on the backlog (e.g. story points). This level of planning and tracking is comparable to using an odometer during your drive. The odometer gives you a more long-term view of velocity when miles are measured against larger units of time, such as hours and days.
- Project - For a cross-country drive, you’ll likely have a map and a rough idea of your progress and stops along the way. You may have a gas budget and looked online to see where major construction delays might occur on your path. If asked where you expect to be tomorrow night, you’d have an answer like “Denver”. If asked where you would be at 2:15 PM tomorrow, you might not be much more precise. Long-term project planning should be like this. It focuses on the major cost, schedule, and feature goals and identifies significant areas of risk. Similarly, long term planning will break out epics and define some constraints based on experience. An example for “online multiplayer gameplay” might be:
- Cost: 10 people for six months to implement and 20 people for six months to produce content.
- Schedule: Starting in June, finishing in 12 months.
- Risk: Online technology risks and core gameplay risks.
Just as we don’t forecast our speed down every mile of road while planning a cross-country drive, a long project shouldn’t forecast what teams will be working on every day for a year or more. Instead, as the planning horizon extends out, the metrics for planning become larger grained and less precise. There are a few reasons for this:
Reason 1: The further out our plan goes, the more uncertainty there is with the details.
This is best illustrated with the cone of uncertainty shown in Figure 2:
Figure 2 - The Cone of Uncertainty
This figure illustrates that the further we are from shipping the game, the more uncertain its cost, scope and schedule. Everyone who has shipped a game should recognize that the great concept art and ideas and plans expressed in the initial design documents usually don’t resemble the shipped game very closely. This is not a bad thing. This is the nature of creating complex games that have a subjective and emotional dimension. We simply can’t “plan away” this complexity and uncertainty. This doesn’t mean we can’t plan. It means we need to plan at a level appropriate to the level of certainty that exists.
Reason 2: Simply breaking down a long term plan into finer details won’t give us more certainty, it’ll give us less uncertainty and waste our time doing it.
This is the hardest to convince people of. The assumption is that a 300 page design document creates twice as much certainly as a 150 page design document. When I worked in the defense industry, this assumption led me to create a 40-pound specification document for an Air Force contract. The Air Force wanted so much demonstrated certainty from their contractors, that they received documents so big they couldn’t read them.
However, numerous studies have shown that not only is uncertainty not reduced equally with more planning effort but, beyond a certain point, the attempt to plan away uncertainty with more effort (documents and spreadsheets) produces forecasts with less accuracy (see Figure 3). The reason that a bigger plan creates less accuracy is due to human nature. It’s in our nature to see a big document and turn off our critical thinking, just as the Air Force did when they saw our 40-pound document. Had they read that document with a critical eye, they would have quickly found out that it was a rushed cut-and-paste job by a junior engineer. Instead, they simply weighed it and awarded us the contract.
Figure 3 - The Accuracy of Planning Based on Effort
The tools that we choose, based on where we are in the planning onion, help us stay in the ideal range of precision, which gives us the best amount of accuracy without wasting effort.
 I’ve seen some teams estimate in “NUTS”, which stand for “nebulous units of time”.
 Although I’ve seen some producers try to do this!
 Ever wonder why new fighter aircraft are years late and billions over budget?
 One of many quote is http://tinyurl.com/leasydl
The Scrum Product Owner must lead the project strategically, collaborate with customers and team on a daily basis, and manage the business value.The Scrum Product Owner takes back the accountability from the traditional project manager for delivering the right solution to the customer and end-user. This two-day CSPO course will provide you with the core […]
The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile and successful. This […]
This 2-day training course provides a deeper understanding of Kanban for knowledge workers. The training is therefore particularly suitable for those who: want to start with Kanban and are looking for initial support have already introduced Kanban and want to check if the implementation complies with state-of-the-art Kanban knowledge This is a certified Kanban training […]
Certified Scrum Master The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile […]
The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile and successful. This […]
Release planning is without a doubt one of the most challenging responsibilities for agile teams… at least that’s what I’ve experienced both personally and while coaching enterprises through transformations.
Most teams are working to deliver solutions where the question of “what will I get” at the end of a release can not be left open ended. Furthermore, these teams don’t have an unlimited capacity. They are working within what appears to be a constrained iron triangle, cost, time and scope are all fixed. Mike Cottmeyer’s recent blog about the agile home builder, discusses this challenge from the perspective of establishing a categorized budget.
It is an approach that I’ve seen work on several occasions. The process is pretty straight forward, not easy… but also not complex
Here’s a script that I like to use to help move teams from “this is impossible” to, “hey I think we can deliver!”Getting Started
Before determining how much of the budget should be spent on features, its important for the team to understand the goal of the eventual release. To help with this, I usually encourage the team to form of a mock press release, announcing their successful release to the world. Typically this includes key areas or attributes of the release that have made the release impactful to the reader. These are now key success areas for the releaseEstablishing your Budget Categories
Each of these key success areas start to emerge as high-level categories within the context of a releases budget that can be used to help focus initial scope conversations. From here the key stakeholders can allocate their budget across each of the category areas.
Quick sidebar, the asset that is available for budgeting is usually the delivery system’s planning velocity.Keep your Eye On the Ball (successful release, budget available)
Now that budget categories are set, the teams need to start working through their release plans and refining their needs for the “right” implementation based on the budget available. There are many methods for going about this process; but, by far my goto method starts with high-level acceptance criteria for each category, or feature area, that can be clarified through a mix of example user journeys or system interactions. The funds available to each of the categories should be brought down and further applied to each of these so that the planning team remembers to keep its eye on the ball. A successful release will need to both (1) deliver the functionality needed, and (2) live within the budget that is available.
This is key, without a focus on the budget available (cost) most teams will struggle to limit the scope of a release until its too late. Early budget constraints help to drive out scope that is not critical to the success of a release.
What do you think, what are your favorite ways to vary scope to successfully deliver on previous market commitments? For more on this topic, take a look at an earlier blog about calculating the budget, in cost, for agile teams.
As a Team Coach or Scrum Master, conflict within a team is something we often have to deal with. Over the years I have come across a number of techniques that help resolve team conflict. Regardless of the technique you decide to use, its important to understand or try to see each individuals map of […]
The post Dealing with team conflict and problem solving – Drama Triangle Model appeared first on ScrumSense.com.
With all the recent talk about agile being dead, we’ve been feeling a dark cloud hanging over us.
Could it really be that it’s time to throw in the towel on agile, to hang up the gloves? Is agile so broken, its principles so polluted? Should we just relinquish ourselves to the couch to watch "Office Space" on permanent loop?
Despite vigorous amounts of coffee and Thriller dance moves, we couldn’t seem to chase this dark cloud away. And then ...
Then it occurred to us that maybe what we really need -- what all of us really need -- is a little inspiration. We need to recharge the very values that make agile so awesome.
We considered agile energy drinks, agile bracelets, and agile ringtones; but then realized, what’s everyone’s favorite form of inspiration? Why, motivational posters, of course.
So, to celebrate this special day, the occasion of our inspiration, we thought we’d share these motivational posters with you, too. Feel free to print out your own copies and frame them for your workspace. We hope you’ll soon feel as inspired as we do!
Wie kann es sein, dass ich immer wieder aufs Neue erlebe, dass in Unternehmen keine Feedback-Kultur gefördert wird? Die Richtlinien des lösungsorientierten Feedbacks sind zwar meist auf dem Unternehmenslaufwerk zu finden, aber dort verstauben sie in ihrer virtuellen Existenz, statt real angewendet werden. Das ist wirklich schade. Feedback ist unwahrscheinlich wichtig, um das Verständnis rund um die kontinuierliche Verbesserung zu fördern. Gegenseitiges Feedback im beruflichen Kontext zu geben und zu nehmen ist elementar, um eine lernende Organisation aufzubauen.
Aus diesem Grund habe ich es mir zur Gewohnheit gemacht, (fast) nach jedem Meeting, Training bzw. Workshop das Feedback meiner Teilnehmer einzuholen und – wichtig – auch Feedback an meine Teilnehmer zu geben. Hier meine drei Lieblingsmethoden.Feedback-Tür
Einfach 4 Post-its an die Tür kleben (++, +, -, –) und die Teilnehmer bitten, beim Verlassen des Raumes einen Punkt auf das zutreffende Post-It zu zeichnen. Das geht schnell, ermöglicht Anonymität, und ist wenig disruptiv. Ich wende das häufig bei „Feedback-Neulingen“ an, obgleich die Methode eigentlich immer passt. Man kann bei dieser Feedbacktür den Schwerpunkt auch konkret auf „Return On Time Invested“ (kurz: ROTI) legen, um herauszufinden, wie viel Mehrwert der Termin den Teilnehmern gefühlt gebracht hat. (Achtung: Bei einem überwiegend negativen Resultat sollte jedoch unbedingt eine Nachbesprechung mit den Teilnehmern erfolgen.)Blitzlicht-Gewitter
Beginnend bei mir selbst, sagt jeder reihum einen Satz. Wie geht es mir jetzt nach dem Termin, wie empfand ich das Meeting, was fand ich gut, was hat mir gefehlt – all das sind Elemente, die hier erwähnt werden dürfen. Kleiner Tipp: Es hilft, einen „talking stick“ herumzureichen (Stift, Ball, Spielzeug o.ä.), um sowohl die Disziplin als auch den Fokus zu fördern. Und wer eine sehr redselige Truppe an Teilnehmern hat, kann ruhig zur Packung Streichhölzer greifen. Wer länger redet, als ein Streichholz abbrennt, der verbrennt sich wortwörtlich die Finger ;)Wie war der Termin?
Bei einer kleinen Gruppe, die sich ohnedies öfter sieht (z.B. Dev.Team), lohnt es sich, nach Abschluss des Termins die ganze Runde bzw. einzelne Personen zu fragen: Wie war der Termin? Was war gut? Was sollten wir das nächste Mal anders machen? So bekommt man Feedback und der nächste Termin kann nur noch besser werden.
Habt ihr auch das Gefühl, dass eine tatsächliche Feedbackkultur im beruflichen Kontext sehr selten zu finden ist? Wie geht ihr damit um?
- Erfolgreiche Meetings in drei Minuten
- Agile Brazil 2010 in Puerto Alegre
- 5 min on Scrum | Es gibt noch viel zu tun
If you’re like us, you want to improve the productivity, quality, predictability, and responsiveness with which you build things. But what’s the best way to really improve your performance? You need to first understand where you are, have the means to get better, and measure your progress over time.
Now Rally can help you improve with new benchmarking tools that let you understand, adapt, and measure your performance.Welcome to Rally Insights.
Rally Insights, currently in beta release, gives you the ability to compare your own performance against a benchmark of over 13,000 teams. Compare the performance of a single team (or program, or entire organization) to its history … or compare it to the average of teams in the workspace … or compare it to an industry benchmark.
To use Rally Insights, just look in the upper left corner of Rally: it's now a product picker!
Select the Rally Insights icon to get started.
You’ll see an overview of your team’s performance compared across the industry; after providing qualitative information about your team through a quick (10-15 minutes) survey, you can even drill down to see details for each dimension of your performance (productivity, predictability, quality, responsiveness.)
Rally Insights builds on the Software Development Performance Index (SDPI) and research that quantifies what behaviors lead to the best performance. This research already has helped teams improve and make essential tweaks that drive more value in their work. To learn more, check out the video series on the Impact of Agile Quantified.
Try the Rally Insights Beta and get your own Rally Insights. Contact your Rally technical account manager or email us at email@example.com for more.Larry Maccherone
Keine Frage: Die Medizintechnik ist ein stark regulierter Bereich. In forschenden und entwickelnden Unternehmen kann das Dickicht an Richtlinien, Normen und Verordnungen zu einem permanenten schlechten Gewissen führen. Gerade in Entwicklungsteams hängt das Thema Dokumentation dann wie eine schwarze Wolke über dem Projekt – nicht selten wird die Umsetzung der regulatorischen Anforderungen so lange wie möglich hinaus gezögert, um sie dann ganz zum Schluss mehr schlecht als recht auf Papier zu bringen.
Dabei geht es auch ganz anders. Regulatorische Anforderungen sind weder Metaphysik noch Mystik. Wer sie kennt und beherrscht, der wird sie bald so normal und banal finden wie Zähne putzen oder Hände waschen. Es geht am Ende darum, sie in den Entwicklungsprozess so einzuflechten, dass sie permanent eingeübt werden. Dazu muss man sie jedoch erst einmal kennen.
Ein guter Überblick über die gängigen Anforderungen ist recht schnell hergestellt. Denn die regulatorischen Anforderungen in der Medizintechnik beziehen sich im Wesentlichen auf vier Bereiche, für die es in Europa jeweils eine maßgebende Norm gibt:
- Qualitätsmanagement mit der Norm EN ISO 13485.
- Risikomanagement mit der Norm EN ISO 14971.
- Lebenszyklus-Prozesse mit der Norm EN 62304.
- Gebrauchstauglichkeit mit den Normen EN 62366 und EN 60601-1-6.
Jedem dieser Bereiche wird in den kommenden Wochen ein einzelner Beitrag gewidmet sein. Heute geht es um die Entkräftung einiger Vorurteile, die einen normalen Umgang erschweren.Vorurteil eins: Die Anwendung der oben genannten Normen ist verpflichtend.
Falsch. Hersteller von Medizinprodukten sind allein dazu verpflichtet, die Anforderungen bestimmter Richtlinien zu erfüllen (v.a. die Medizinprodukt-Richtlinie 93/42/EWG). Die dort formulierten Vorgaben sind jedoch so allgemein gehalten, dass sie nicht unmittelbar handlungsweisend sind. Beispielsweise findet sich dort die Forderung, dass “durch Anwendungsfehler bedingte Risiken aufgrund der ergonomischen Merkmale eines Produktes” so weit wie möglich reduziert werden sollen. Wie die Umsetzung geschehen soll und welcher Prozess dafür anzuwenden ist – darüber sagt die Richtlinie nichts. Die europäischen Normen füllen dieses Vakuum und treten als Umsetzungshilfen der Richtlinie an. Mehr noch: Wer die europäischen Normen einhält, der kann davon ausgehen, dass die entsprechenden Anforderungen in der Richtlinie ebenfalls erfüllt sind (im Fachjargon sagt man, die Norm sei mit der Richtlinie “harmonisiert”).Vorurteil zwei: Die Normen für die Medizintechnik sind ganz spezieller Natur.
Nicht überall. Die Norm zum Qualitätsmanagement (EN ISO 13485) ist beispielweise in großen Teilen deckungsleich mit der weit verbreiteten ISO 9001.Vorurteil drei: Software-Entwicklung ist den gleichen Richtlinien unterworfen wie die Hardware-Entwicklung.
Seit ihrer Überarbeitung im Jahr 2007 findet sich in der Medizinprodukt-Richtlinie die Forderung, dass der Software-Lebenszyklus nach dem Stand der Technik entwickelt werden soll. Die dazu korrespondierende Norm EN 62304 beschäftigt sich nur mit der Software-Entwicklung und beschreibt die einzelnen Phasen von der initialen Produktplanung bis zur Wartung. Spannenderweise legt sie sich nicht auf einen Entwicklungsframework fest, sondern bleibt hier offen. Inkrementelle und evolutionäre Ansätze werden als mögliche Herangehensweisen explizit erwähnt.
Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlag