Skip to content

Feed aggregator

5 minutes on regulations – wie gute Prozesse in der Medizintechnik Innovation verhindern

Scrum 4 You - Mon, 09/01/2014 - 07:30

Ich hatte letztens das Vergnügen, drei Stunden Einführung in RUO und IVD Regulatorien zu bekommen. RUO steht für “Research Use Only” und IVD für “In Vitro Diagnosis”.[1] Diese strengen Richtlinien der FDA (Food And Drug Agency) beschreiben, was ein Hersteller vorweisen muss, damit die FDA seine Produkte auf dem amerikanischen Markt zulässt.

Ich kann hier gar nicht auf all das eingehen, was gefordert wird, aber ich habe zwei Zahlen für euch: Für ein RUO-Produkt – also eines, das nur für Forschungszwecke herangezogen werden darf – müssen ungefähr 2500 Seiten Dokumentation an die FDA geschickt werden, auf denen sorgfältig festgehalten wurde, wie dieses Produkt funktioniert. Ein IVD-Verfahren verlangt ungefähr 10.000 Seiten Dokumentation.

Das aber in Wahrheit Merkwürdige: Wer ein IVD-Produkt einreichen will, muss nachweisen, inwieweit dieses Produkt im Vergleich zu einem bereits bestehenden Produkt besser ist. In irgendeinem Faktor. Es wird also nur etwas Neues mit etwas Altem verglichen. Wer etwas noch nie Dagewesenes erfindet, muss sich also mit der FDA darüber einigen, wie man damit umgehen will.

Okay, das ist noch alles irgendwie verständlich. Es geht um das Leben von Menschen und da müssen Fehler so weit als möglich vermieden werden. Aber jetzt wird es noch faszinierender: Angenommen, man hat die Zulassung und will etwas am Gerät verändern – sagen wir, das User Interface der Adminoberfläche eines computerunterstützten Produkts. Dann könnte es passieren, dass alle 10.000 Seiten erneut eingereicht werden müssen. Ach ja, das Ganze kostet ca. 250.000,- US Dollar.

Sicher, wer will entscheiden, ob es nur eine kleine, unbedeutende Änderung ist, oder eine mit schwerwiegenden, vielleicht noch nicht absehbaren und möglicherweise tödlichen Folgen. Aber was sich damit natürlich wie von selbst erledigt, ist Innovation. Innovation findet, wie wir spätestens seit dem Buch „The Innovator’s Dilemma“ wissen wissen, am Rand – “in the fringe” – statt. Da, wo es noch keine großen Gelder gibt. Da, wo noch nicht klar ist, wie etwas funktioniert. Es zeigt sich im Kleinen.

Prozesse wie jene der FDA sind notwendig, keine Frage – doch wir brauchen intelligente Antworten darauf, wie wir diese Anforderungen erfüllen. Wir brauchen diese Antworten, weil wir auch in der Medizin noch viele Probleme lösen müssen.

[1]“In vitro diagnostic products are those reagents, instruments, and systems intended for use in diagnosis of disease or other conditions, including a determination of the state of health, in order to cure, mitigate, treat, or prevent disease or its sequelae. Such products are intended for use in the collection, preparation, and examination of specimens taken from the human body. [21 CFR 809.3]” Mehr Information dazu hier

Related posts:

  1. Tuberculosis – The pandemic of the 19th century is back?
  2. Der Product Owner / Story Writing
  3. Mit Agil richtig dokumentieren

Categories: Blogs

Learning about Risk & WIP from Real Life

David J. Anderson & Associates - Mon, 09/01/2014 - 03:40

I find that real life examples can help people understand why you can't talk about kanban systems without talking about risk, and why you can't calculate WIP limits without understanding work item types, risk and classes of service. Consider the humble problem of "how many shirts do you need hanging in your closet?"...

read more

Categories: Companies

Sneak Peak at Modern Management Framework

David J. Anderson & Associates - Sun, 08/31/2014 - 03:55
Image: 

In China, "Kanban" simply means "looking at the board." For a Chinese audience, Kanban is encapsulated in the cartoon on the cover of my Kanban: Successful Evolutionary Change for your Technology Business. They don't need to look further than the characters standing in front of the board. Hence, to a Chinese mind, our management approach is centered around a standup meeting. All well and good and why not?

However, a senior executive at one of our clilents felt that this perception was likely to undermine the true value and the potential impact of our teachings on his business. So he suggested that we give the wider collection of ideas, intellectual property and teaching tools, a different name. It so happens I'd been thinking along similar lines and introducing terms and branding in our business to lay the foundation for this. So here it is, "The Modern Management Framework." This isn't new. It's the collection of our existing class curriculum and consulting tools but presented altogether in one place for the first time and under one banner.

read more

Categories: Companies

Visualisierung in Projekten: Braucht Skalierung Tools?

Scrum 4 You - Fri, 08/29/2014 - 07:54

“Big Visible Charts” war einmal das Motto – Scrum-Teams wollten schnell ihre Informationen an jene mitteilen, die daran vorbeigehen. Ein wundervolles Beispiel für diese Variante der Informationsverbreitung findet sich hier. Die Idee war es, physisch und haptisch, schnell und ohne viel Aufwand Teams zu ermöglichen, effektiver zu arbeiten.

Dann kamen die Leute, die unbedingt die große, allumfassende Visualisierung über alle Projekte haben wollten. Sie setzen immer noch Entwickeln mit Produktion gleich und wollten per Mouse Click haben, was bis dato kein MS Projekt Ghantt-Chart konnte: Tagesaktuelle, verlässliche und korrekte Zahlen über den Entwicklungsfortschritt liefern. Sprich: Reporting bis zum Exzess.

Findige und geniale Entwickler wie zum Beispiel die Jungs von Atlassian bauten coole Tools wie Jira, Greenhopper, und einige andere entwarfen die wirklich abgefahrenen Lösungen wie Trello, VerisonOne, Mingle und wie sie alle heißen, damit sie die geforderten Informationen möglichst schnell und einfach liefern konnten.
Und was passiert jetzt: Es gibt Software-Entwickler, die ihr Geld damit verdienen, z.B. JIRA für Kunden zu konfigurieren, die Workflows anzupassen, und aus der simplen Idee von drei Spalten – TODO, INPRG, DONE – wochenlange Entwicklungsprojekte zu machen. Das ist zwar eine tolle Einnahmequelle und wir als Scrum Consulting Firma werden vielleicht sogar schwach und machen das bald auch – aber das war nicht der Sinn und die Idee hinter alldem. Was wir wollten, war ganz einfach: Wissensarbeit sichtbar machen, damit man darüber sprechen kann. Mehr nicht. Damit ein Teammitglied dem anderen helfen kann. Damit klar wird, wo es noch Lücken gibt und wo man sofort eingreifen kann.

Die Entwicklung geht aber leider in die – meines Erachtens – falsche Richtung. Scrum Entwicklungsteams werden automatisiert dazu gezwungen, über jede Story und jede Zeile Code Rechenschaft abzulegen. Ihre  Chefs, leider oft auch die Product Owner, müssen das nicht. Warum eigentlich? Wieso wird von den Entwicklern diese Transparenz erwartet, nicht aber von denjenigen, die die Ansagen machen?
Meine klare Vermutung: Es würde zu deutlich zeigen, dass dort gar nichts produziert wird. Dort wird keine Leistung, keine Wertschöpfung erbracht. Erklären Sie doch einmal der nächsthöheren Ebene, was Sie den ganzen Tag in den 6 Meetings zu je 90 Minuten und in den 10 Telefonaten dazwischen produziert haben.

Wir haben in unserem Unternehmen die Beweiskette, den Nachweis, dass etwas passiert, umgekehrt. Ich muss klar darlegen, was ich tue. Ich führe ein Backlog, das sich alle in einem Confluence Wiki ansehen können. Dort stehen alle Aktivitäten (fast alle – ich vergesse auch mal was), die ich an einem Tag ausführe, und ich lege die Ziele ebenfalls öffentlich ab. Nicht weil ich sie vorgeben will, sondern weil wir sie nur dann diskutieren können, wenn wir sie immer wieder sehen. Man kann nur über etwas reden, das man offenlegt.

Und wisst ihr, was passiert ist? Es hat Schule gemacht. Jeder legt nun das, was er tut, ganz von selbst offen. Wir haben noch kein Taskboard – noch nutzen wir ein Wiki. Vielleicht nutzen wir auch bald mal JIRA intern ;-)  - als verteiltes, skaliertes und multikultures Team. Aber nicht, damit mir meine Kollegen reporten, sondern damit sichtbar wird, wer gerade woran arbeitet und sich die Kollegen gegenseitig helfen können – egal, wo sie gerade sitzen. Internationalisierung, das remote Arbeiten und das ständige mobil Onlinesein lässt sich nicht mehr zurückdrehen. Wer diese Geschwindigkeitsvorteile nutzen will, darf Tools für die  Zusammenarbeit über die Grenzen eines Büros hinaus nicht mit Reportingtools für das Management verwechseln oder sie dafür missbrauchen.

Related posts:

  1. DeutscheScrum
  2. Eindrücke eines Teilnehmers an CSM Training mit ScrumCooking
  3. Scrum Tools | Protonotes | Review

Categories: Blogs

The Agile Reader – Weekend Edition: 08/29/2014

Scrumology.com - Kane Mar - Fri, 08/29/2014 - 04:22

You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • RT @ScrumDan: Embrace Change + Learn from Mistakes = Successful Agile Implementation #agile #scrum
  • Are you implementing Scrum but realize you are better suited for Kanban? #Agile #Scrum #Kanban
  • RT @braintrustgroup: Benefits of #Scrum – Management Perspective: Enhanced Stakeholder relationships #project #agile…
  • RT @DM_Lorenzo: 9 Tips to manage your #SoftwareDevelopment projects #agile #scrum please RT
  • Benefits of #Scrum – Team Perspective: A safe working environment where people can thrive. #software #project #agile
  • RT @braintrustgroup: Benefits of #Scrum – Team Perspective: A safe working environment where people can thrive. #sof…
  • RT @yochum: Agile Denver Session Notes: Unscaling #agile #scrum
  • Retrospectives Pre-Requirements – #retrospectives #scrum #agile
  • Cynefin and Story Splitting #agile #scrum
  • A #scrum master who relies on command & control is an impediment, not a servant leader. #agile http://t.co/7um5M4RaEv
  • Are you struggling with backlog refining meetings that aren’t productive? #Scrum #agile #BacklogRefining #Estimating
  • RT @ryanripley: A #scrum master who relies on command & control is an impediment, not a servant leader. #agile http:…
  • [vidéo] Legos, méthode agile Scrum 3D et imagination : The LEGO House By B.I.G via @_theinspiration
  • Planning, Tracking and Managing Agile Web Development Sprints using Scrum and Intervals ~ http://t.co/czeCMz14Nf
  • - Short weekly blog based around Scrum and Agile… http://t.co/8aMEyXOxiV
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • The Board – Episode 34 – Scrum vs. Kanban #Scrum #Agile
  • The Board – Episode 34 – Scrum vs. Kanban #Scrum #Agile
  • Avenue Code is offering a 2-day Certified Scrum Master Training. Here is more info! #scrum #agile #training
  • Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile inspired by #kschwaber
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Ken Schwaber talks to InfoWorld about the origins of #Scrum: #agile
  • RT @JamesMDonovan: DevOps #IBMRational web session: — Agile/SCRUM features coming in v5.0.1 of Team Concert, presen…
  • The Board – Episode 35 – Agile Fluency #Scrum #Agile
  • The Board – Episode 35 – Agile Fluency #Scrum #Agile
  • How does #availabilitybias affect #projectmanagement? via @RichEarthPM #scrum #agile #pm #project
  • Two week sprints is the standard, but a different length might be better for your team or project #scrum #agile
  • Site catalyst Analyst – Adobe Analytics Agile SCRUM – (Seattle) #Seattle #WA #News
  • #Agile #Scrum Sprint Length: Whats Right for You? My 2c: The key consideration is the PO’s ability to release value.
  • RT @dr_ian_mitchell: #Agile #Scrum Sprint Length: Whats Right for You? My 2c: The key consideration is the PO’s abil…
  • Agile Software Development with Scrum and press release #agile
  • RT @sdtimes: Experts explain how to transition to agile, best practices and what to watch out for #agile #scrum #kan…
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @IBMCSC: #IBMCSC Brazil 18 adopting Agile Scrum to help preserve the rainforest w/ @nature_org #HelpsCSCBrazil @M…
  • Site catalyst Analyst – Adobe Analytics Agile SCRUM – (Seattle) #Seattle #WA #News
  • Check out this Meetup TONIGHT with Portland Agile & Scrum Meetup Group! 6:15 at ADP Plaza.
  • RT @PDXProductCamp: Check out this Meetup TONIGHT with Portland Agile & Scrum Meetup Group! 6:15 at ADP Plaz…
  • #Strongsville, OH #IT #Job: Agile Scrum Master – Project Manager 14-266 at Medical Mutual #Jobs
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @braintrustgroup: Benefits of #Scrum – Team Perspective: A safe working environment where people can thrive. #sof…
  • The Board – Episode 36 – Designing Agile Spaces #Scrum #Agile
  • The Board – Episode 36 – Designing Agile Spaces #Scrum #Agile
  • RT @scrumology: The Board – Episode 36 – Designing Agile Spaces #Scrum #Agile
  • RT @scrumology: The Board – Episode 34 – Scrum vs. Kanban #Scrum #Agile
  • Site catalyst Analyst – Agile SCRUM Adobe Analytics – (Seattle) #Seattle #WA #News
  • Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • RT @eegrove: Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • RT @DeloitteDIGI_US: Scrumban: A different way to be Agile – @paulgambill #scrum #scrumban
  • Site catalyst Analyst – Adobe Analytics Agile SCRUM – (Seattle) #Seattle #WA #News
  • Can you explain the Benefits of #Scrum from multiple perspectives? Here’s a summary that is helpful – #product #agile
  • RT @eegrove: Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • RT @eegrove: Next Agile Ottawa Meetup Tues Sept 9! @pg5150 talking about User Story Mapping – don’t miss it
  • The Board – Episode 35 – Agile Fluency #agile #scrum
  • The Board – Episode 36 – Designing Agile Spaces #agile #scrum
  • RT @yochum: The Board – Episode 36 – Designing Agile Spaces #agile #scrum
  • RT @yochum: The Board – Episode 36 – Designing Agile Spaces #agile #scrum
  • Low-code development platforms #scrum #agile
  • FREE SCRUM EBOOK #Scrum #Agile inspired by #Ken Schwaber
  • Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #AppsTrans #HP
  • RT @ReleaseTEAMLTD: Agile Software Development with Scrum and press release http://t.co/RvU6…
  • Here’s a video explaining #agile #development team best practices w/ #scrum particle physics @SolutionsIQ
  • RT @MichaelNir: #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Project Manager – Urgent – Prince 2, Agile, Scrum, Budget, CRM Job Crawley
  • I’m attending a Meetup with Portland Agile & Scrum Meetup Group http://t.co/N26shzEGpQ
  • Agile by McKnight, Scrum by Day is out! Stories via @AntonyMarcano @EmmyHermina
  • RT @versionone: Here’s a video explaining #agile #development team best practices w/ #scrum particle physics @Soluti…
  • Transparency in your daily life is so damn important. Especially at your job. #Scrum
  • RT @IBMCSC: #IBMCSC Brazil 18 adopting Agile Scrum to help preserve the rainforest w/ @nature_org #HelpsCSCBrazil @M…
  • Categories: Blogs

    This is Way Better Than the Ice Bucket Challenge!

    The Agile Management Blog - VersionOne - Thu, 08/28/2014 - 22:16

    If you feel like there’s a lot of time being idled away on the Ice Bucket Challenge and other wacky, brainless activities, we have a better idea to spend your time. In just 10 minutes you could do something really valuable for the agile software community.

    But first I’m hoping to get just a tiny smile out of you by sharing something I wrote on our Product Blog earlier this week — just in case you aren’t subscribed there. If you are, just ignore this and go straight to the punch line.

    I posed this question:

    What’s the Best Way to Spend 10 Minutes?

    Let’s think about this for a minute…

    You could:

    • Ice-bucket challenge someone
    • Set a stapler in a Jell-o moldStapler
    • Crash someone’s Facebook by inviting them to Candy Crush
    • Add a ‘Blue Screen of Death’ screen saver to your boss’s laptop
    • Load a DVORAK driver onto a PC with a normal keyboard
    • Clean those 24 sticky coffee rings off your desk
    • Assign a bunch of fake stories to people

    But if you really want to make a lasting and meaningful impact on the agile software community, please find 10 minutes to take the 2014 State of Agile survey.

    Why?

    2014_SOA_banner_300x250

    “The annual State of Agile survey has become one of the most comprehensive industry surveys serving the agile community. The survey gives agile software professionals an extensive set of relevant statistics, peer guidance and validation that can be very helpful in making smarter decisions about their delivery process.”

    - SD Times Editor-in-Chief David Rubinstein

    Now in its 9th year, the State of Agile has helps agile practitioners, consultants, technology students, professors, bloggers and business people in all industries better understand agile methods and practices. The survey runs late summer through mid-September and VersionOne publishes the report in Q4 or early Q1.

    If you take it, you get:

    • Entered into a drawing for 1 of 9 SONOS wireless HiFi systems (each worth 600 bucks)
    • Exclusive, early access to the data sample from 2,000-4,000 respondents in your industry
    • Satisfaction that you helped others make informed decisions about their agile practices – in just 10 minutes

    What are you waiting for? Take the State of Agile survey now.

    take survey now image

     

    Categories: Companies

    Managers Manage Ambiguity

    Johanna Rothman - Thu, 08/28/2014 - 17:47

    I was thinking about the Glen Alleman’s post, All Things Project Are Probabilistic. In it, he says,

    Management is Prediction

    as a inference from Deming. When I read this quote,

    If you can’t describe what you are doing as a process, you don’t know what you’re doing. –Deming

    I infer from Deming that managers must manage ambiguity.

    Here’s where Glen and I agree. Well, I think we agree. I hope I am not putting words into Glen’s mouth. I am sure he will correct me if I am.

    Managers make decisions based on uncertain data. Some of that data is predictive data.

    For example, I suggest that people provide, where necessary, order-of-magnitude estimates of projects and programs. Sometimes you need those estimates. Sometimes you don’t. (Yes, I have worked on programs where we didn’t need to estimate. We needed to execute and show progress.)

    Now, here’s where I suspect Glen and I disagree:

    1. Asking people for detailed estimates at the beginning of a project and expecting those estimates to be true for the entire project. First, the estimates are guesses. Second, software is about learning, If you work in an agile way, you want to incorporate learning and change into the project or program. I have some posts about estimation in this blog queue where I discuss this.
    2. Using estimation for the project portfolio. I see no point in using estimates instead of value for the project portfolio, especially if you use agile approaches to your projects. If we finish features, we can end the project at any time. We can release it. This makes software different than any other type of project. Why not exploit that difference? Value makes much more sense. You can incorporate cost of delay into value.
    3. If you use your estimate as a target, you have some predictable outcomes unless you get lucky: you will shortchange the feature by decreasing scope, incur technical debt, or increase the defects. Or all three.

    What works for projects is honest status reporting, which traffic lights don’t provide. Demos provide that. Transparency about obstacles provides that. The ability to be honest about how to solve problems and work through issues provides that.

    Much has changed since I last worked on a DOD project. I’m delighted to see that Glen writes that many government projects are taking more agile approaches. However, if we always work on innovative, new work, we cannot predict with perfect estimation what it will take at the beginning, or even through the project. We can better our estimates as we proceed.

    We can have a process for our work. Regardless of our approach, as long as we don’t do code-and-fix, we do. (In Manage It! Your Guide to Modern, Pragmatic Project Management, I say to choose an approach based on your context, and to choose any lifecycle except for code-and-fix.)

    We can refine our estimates, if management needs them. The question is this: why does management need them? For predicting future cost for a customer? Okay, that’s reasonable. Maybe on large programs, you do an estimate every quarter for the next quarter, based on what you completed, as in released, and what’s on the roadmap. You already know what you have done. You know what your challenges were. You can do better estimates. I would even do an EQF for the entire project/program. Nobody has an open spigot of money.

    But, in my experience, the agile project or program will end before you expect it to. (See the comments on Capacity Planning and the Project Portfolio.) But, the project will only end early if you evaluate features based on value and if you collaborate with your customer. The customer will say, “I have enough now. I don’t need more.” It might occur before the last expected quarter. It might occur before the last expected half-year.

    That’s the real ambiguity that managers need to manage. Our estimates will not be correct. Technical leaders, project managers and product owners need to manage risks and value so the project stays on track. Managers need to ask the question: What if the project or program ends early?

    Ambiguity, anyone?

    Categories: Blogs

    AgileCraft 8 Enterprise Agile Tool Launched

    Scrum Expert - Thu, 08/28/2014 - 17:37
    AgileCraft has announced general availability of AgileCraft 8. AgileCraft’s integrated platform provides transparency across the entire software lifecycle, enabling rapid value delivery and better, more predictable results. Built from the top-down to support enterprise agile at scale, the latest version brings new capabilities across all four levels: enterprise, portfolio, program and teams. AgileCraft 8 helps align the whole organization around common goals and objectives, providing actionable views and metrics to everyone touching the product lifecycle. The AgileCraft approach empowers customers to scale with existing tools like Atlassian, TFS, Rally, etc. while adding ...
    Categories: Communities

    Agile Coach Camp, Indianapolis, USA, September 26-28 2014

    Scrum Expert - Thu, 08/28/2014 - 15:05
    The Agile Coach Camp is a three-day conference about Agile Coaching run by agile coaches for agile coaches based on peer-to-peer learning and exploration in an OpenSpace setting. In this type of conference, people come together around a high-level topic or need and create their own agenda; then people gather into groups to brainstorm, debate, collaborate, co-create, plan, play, tell stories, and discuss the topics proposed on the agenda Web site: http://www.agilecoachcamp.us/ Location for the 2014 conference: Hilton Indianapolis, 120 West Market Street, Indianapolis, Indiana, USA 46204
    Categories: Communities

    Flow Is For Sissies

    Leading Agile - Thu, 08/28/2014 - 14:25
    Flow: Nice Work If You Can Get It

    A number of years ago I worked with an EDI (Electronic Data Interchange) team that was troubled with a large level of WIP (Work In Process) and slow movement of work through a system with many external dependencies. Work was regularly blocked waiting for unresponsive peers from the other companies. Work would languish in partially completed states and eventually be abandoned, either because the business relationship changed or the team gave up and turned their attention towards more likely prospects.

    Looked like great place to apply kanban

    These sounded like great problems to solve with the help of the Kanban Method and I was eager to get started. This thinking, however, set us on an educational but somewhat fruitless path. The results weren’t what we expected.

    Applied the Kanban Method

    We mapped out the value stream, modeled it appropriately in a kanban, and used the kanban system for a while to get visibility into the process and gain understanding. That was a success.

    The Kanban Method helped us confirm that each analysis, development and QA step in their value stream took little value-added time. Nothing unusual or out of the ordinary was happening in any of the stages. We weren’t worried about vacations or someone getting hit by a bus. There were no bottlenecks.

    The kanban helped us discuss Lean concepts and apply them to our situation.

    Got some benefits but nothing real or substantial – no WIP reduction or lead time reduction

    Our initial goal was to visualize the process, reduce WIP, simplify prioritization, and look for improvement in lead-time, especially through reduction in delay. We got the visualization and felt we didn’t need as much as we got. We more fully understood the amount of WIP, but limiting it would not enable any additional swarming. Perhaps we got the simplified prioritization, but that came more from understanding the system and lean principles than from the Kanban Method or the kanban (the board) itself.

    We didn’t achieve the lead-time reduction. We couldn’t. The delay was outside of our control.

    Outside of our control

    The root cause was that the team was waiting for external IT shops to complete their part of the equation. It took several rounds of interactions with multiple people outside our company to complete a job. After our team did a little processing, the work item went to sleep in a blocked state and (maybe, someday) would be woken up by the external IT shop if they should decide to respond to our pleading.

    Our group would benefit greatly from setting up EDI with their numerous business partners, but the other companies had no incentive to do their part of the connection. (Perhaps you are thinking that we needed to give them a financial incentive. We explored many ideas that just didn’t fit into our sales or business model. Changing the business model was another avenue of exploration but let’s save that for another post.) The times that the external group did respond, it was likely because they had some slack time and/or thought the task was interesting or challenging.

    It didn’t matter anyway

    It really didn’t matter anyway.

    Every integration with a 3rd party is of high value to our business — worth the cost of abandonment of work on a large percentage of opportunities. Each successful company pushed through the process is so valuable that it more than covers the costs incurred with those that fail.

    Therefore, it was more important to have many “at bats” or “sales calls” than it was to have a short lead-time. Well, maybe ‘important’ isn’t the right word. It’s very important to complete work quickly, but in this case, it’s achievable to have more sales calls. We couldn’t improve our lead-time no matter how important that is.

    A better way to look at it is we had extra capacity and used that to push more companies through the process (or, to create demand). We reached equilibrium where a hit suspends additional tries at-bat, and more at-bats ultimately increase hits. Work with an engaged external IT guy competes with making more sales calls. More sales calls yield additional willing external partners.

    Yes, that will build up significant WIP over time. Whether we control WIP or not, many of the external companies aren’t going to cooperate and finish the process. We will abandon a lot of work. We try hard to finish whatever we start, but we can’t tell which work will be abandoned before we start.

    Ultimately, we considered the cost of being a low priority and deemed it worth it.

    Lesson learned

    Until this experience, I didn’t fully understand the lean principle of Value trumping Flow and Waste Reduction, a lean principle. I was aware of it, but I only thought I understood it. I knew that sometimes we should accept uneven flow if it helps us get value, but I was thinking that would only ever be exception cases. I was thinking that the norm should be to optimize smooth flow. The implication I had missed is that smooth flow isn’t always a general prerequisite for value. Considerable waste and huge WIP and horrible flow might just get you the most value.

    (Anyone can get value if you have flow. This kind of environment isn’t for sissies.)

    Finally, I began to think about this situation with the EDI team as having options, rather than as a great place to apply the Kanban Method or Lean Principles. I began to see the options in the system trumping the considerable waste, huge WIP and horrible flow.

    The moral of the story is that real options thinking, systems thinking and many other such concepts present or yet to come may be more appropriate in some cases than Lean/Kanban thinking. Lean/Kanban thinking is useful, but it isn’t all there is.

    Somewhere in the last decade, I had a similar revelation about eXtreme Programming.

    With every shiny new hammer, I find more things that look like nails.

    The post Flow Is For Sissies appeared first on LeadingAgile.

    Categories: Blogs

    Using Commercial Scrum Tools for Free

    Scrum Expert - Tue, 08/26/2014 - 14:50
    If the development of open source Scrum tools was in vogue some years ago, a lot of these projects have now been abandoned. Some are still active like IceScrum or ScrumDo, but this is because their development is sponsored by a commercial hosted option There is however an alternative to manage your Agile project if you have a low budget… and a small team. Some providers of commercial Scrum tools provide a free version of their software. Only Scrum tools that offer a long term free product are mentioned in this ...
    Categories: Communities

    Learn a new domain every year

    TargetProcess - Edge of Chaos Blog - Thu, 08/14/2014 - 23:25

    How diversity helps us in problem solving, creativity and overall intelligence? It helps a lot. Diverse groups of people can produce better results and radiate more creativity. But what about your own, personal diversity? Is it a good idea to accumulate knowledge from wide range of disciplines? Does knowledge of music theory help to write better code? Does knowledge from biology make you a better user experience designer? I believe yes, and here is why.

    untitled_3_by_mpcine-d5simvn

    source: Escher Butterfly Wallpaper by MPCine

    Douglas Hofstadter and Emmanuel Sander wrote a very controversial book Surfaces and Essences. It is not an easy read, but it is time spent well. Authors unfold thinking process from language to high level constructs. They show how analogy-making helps us think, generate new ideas and fuel our creativity, including scientific insights.

    This book deeply resonated with me. In general I agree that analogy-making is a core of our creativity. I even tried to apply knowledge from Running domain to Software Development domain and generated some quite interesting ideas like Interval development. Sure these ideas can’t be proved easily, since analogy doesn’t mean the idea is great. But still it is relatively easy to take knowledge from one domain and apply it to another domain.

    How can it help me?

    All that brought me to the idea to increase my personal diversity and expand my knowledge beyond typical areas like system thinking, software architecture, groups dynamic, innovation models, user experience and other stuff every CEO learns. I read books and took courses about quite diverse topics already, but I did that in a chaotic way.

    Suddenly it became obvious to me how all these new domains can help me to be more creative and solve problems better.

    What domains should I explore?

    I think you should try anything you always wanted to learn, but didn’t have time to. It is quite hard to predict what analogies can be generated from unknown domains. For example, you always wanted to know how people paint, how art evolved and how Michelangelo painted a fresco of The Last Judgement on the altar wall of the Sistine Chapel. Dig into the art domain and learn as much as you can in a single year. Will it help you to be a better software developer? Why not? If you try to paint something you can train patience and learn how to sketch (everybody should sketch, you know). Michelangelo’s approaches may give you some ideas how to structure your work. As I said, it is hard to predict exact ideas that you’ll generate in the end, but I promise you will generate some.

    I personally want to study biology, music theory, architecture, education, medicine, go and swimming. If a simple running domain gave me new insights, I believe larger and more complex domains will bring even more value.

    Why one year?

    A year is a good timeframe to focus on something. It will be your new hobby for a full year. You can read 20+ books, take 1-3 online courses, maybe take offline courses, try to apply your new knowledge constantly. Small domains demand less time, but larger domains are hard to grasp in 2-3 months.

    I don’t believe in quick solutions. You can read a book or two about a subject and have some fresh air in your head, but it is not enough to just scratch the surface. In 10 years you will have a decent knowledge in 10 domains. That sounds cool to me.

    Did you try that?

    Nope. I started to dig into music theory recently. So far I’m just sharing the idea with a hope that there is always a chance you’ll like it and give it a try.

    And maybe, just maybe, you’ll even find your new passion. Who knows?

    Categories: Companies

    Agile Conference Revolution

    TargetProcess - Edge of Chaos Blog - Sun, 08/10/2014 - 22:16

    This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.

    I haven’t visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I’m in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.

    How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don’t get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How’s that happened?

    Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?

    There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.

    SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won’t work in many cases, and you can’t fix it without context-awareness.

    SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don’t believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.

    So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.

    I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C’mon, folks, this separation is childish.

    All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:

    1. Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
    2. Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don’t do that on sessions as well?
    3. There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
    4. Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
    5. 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I’d like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.

    In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can’t imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.

    The final thing is the slogan I saw yesterday. It is just unbearable to me: “Allow agile and waterfall work together” WTF?

    BtvFR0oCAAAZXtN

    I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.

    “Pirates are bold not safe” — These guys are doing something good

    Categories: Companies

    [Recap] Fast IT: Concepts and Examples from Assembla and Attivio

    Assembla Blog - Thu, 07/31/2014 - 22:51

    Last week, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla presented a webinar about “Fast IT,” a new way of managing rapidly changing and Agile projects in areas like mobile, Web, analytics and marketing applications, while working smoothly with reliable core systems ("Core IT"). Andy discussed the dynamics of Fast IT, and Sid presented a case study of how Attivio spun up a major Business Intelligence app in two weeks with two people.

    If you missed the webinar, view and download the slides

    Want an overview of Fast IT in 60 seconds? Watch the video below:

    Get notified about new and exciting content around Fast IT by completing the form below:

    //

    Categories: Companies

    Assembla now allows automatic payments with PayPal

    Assembla Blog - Fri, 07/25/2014 - 20:17

    Paying for your Assembla subscription with PayPal has never been easier. We recently added the ability to set up recurring payments with PayPal that will automatically pay for your Assembla subscription every billing period, whether that be monthly or annually. Previously, it was a manual process that required logging in and paying every time an invoice was created.

    To set up automatic payments with PayPal, visit your billing page > select the PayPal option > and follow the steps.

    assembla paypal option1

    If you have any questions or issues, please contact Assembla support at support@assembla.com.

    Categories: Companies

    Workplace Design: Creating a Home from Home

    Agile Coaching - Rachel Davies - Wed, 07/23/2014 - 16:43

    LolaLast week one of our stakeholders brought his pug dog, Lola, along to our product review meeting. “Watch out, she likes feet!” he joked but she remained quiet and well behaved throughout the meeting. Unruly is not the only place I’ve come across where dogs have been accommodated at work, another had a dog basket in their main board room. I appreciate not everyone likes dogs around but I like working for a company that’s not too stuffy to allow people flexibility to make our workplace more homely.

    We’re lucky at Unruly to have a dedicated People & Places team who work closely with our Design team create a work environment that has personal touches. There are many informal meeting places around the building to make collaboration easy and it’s decorated with original artwork GoldFramePortalreflecting our culture. Little things amaze visitors as we show them around, for instance we created a two-way webcam portal between our London and New York office with a gold antique-style frame, which makes it seem more special and echoes Harry Potter where characters move around. What’s the business case? Creating an environment that allows human expression encourages creativity to flourish in our work.

    The design of our workspace is not owned by a central team outside development. We recently reorganised our desks and unlike many companies, where a "Desk Move" is a dreaded logistical nightmare involving packing things up for another team to execute overnight, our developers simply got stuck into disassembling desks and lifting floor tiles themselves to get everything in the right place. Our spirit of collective ownership and taking responsibility for how our code structured seems to extend out to our surroundings. Taking care of our workspace, isn’t somebody else’s job. DeskMove

    Our teams use our walls and whiteboards for practical purposes but with a sense of humour too. Even electronic tools get a bit of customisation, we use Trello for our backlogs and teams can add distinctive backgrounds to make them easier to pick out.

    Teams in bigger companies often find that their boards are the easiest areas to start personalising, when you introduce Kanban boards you can involve everyone on the team in designing the layout. Rather than diving straight in to moving things around, you can create a mini-version of the new layout with sticky notes. I think it’s important to give everyone on the team the opportunity to mull the proposed design over and allow time for tweaks. We’ve taken this approach with how we lay out our boards and our desks (as in the examples below).

    Desklayout
    BoardLayoutI appreciate that many people work in organisations that don’t actively support personalisation of the workspace but you can start small with a potted plant, a team mascot, a little whiteboard artwork. You'll likely find personal touches are noticed and soon start to spread around surrounding teams. Another small step that you can take is to adopt iteration names or pictures that pick up on what’s going on in the outside world or reflect metaphorically on current mood within the team. In software development, we spend a lot of time in an office environment, taking care of your surroundings helps to take care of the people working within them.

    Categories: Blogs

    Broadening Developer Horizons

    Agile Coaching - Rachel Davies - Thu, 07/17/2014 - 16:28

    XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.

    To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.


    To make collective code ownership easier, some product teams select a homogeneous stack such as Clojure with ClojureScript or JavaScript all the way down using Node. At Unruly, our developers need to be fluent in JavaScript and Java with a smattering of Scala. Full-stack developers are bright people who can keep pace with developments in multiple languages and frameworks rather than immersing themselves in a single core development language. Being a full-stack developer is more than being able to write code in different languages, you have to understand idioms and patterns for UI, middleware, database realms too.

    Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.


    As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is mUsing-laptop-on-snowy-mountainore than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scatches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.

    As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).

    We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.

    There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resiliant to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!

    Categories: Blogs

    Post Assembla events to your favorite chat apps: Slack, HipChat, Flowdock & more

    Assembla Blog - Wed, 07/16/2014 - 02:26

    If your team uses Slack, HipChat, Flowdock, or Bigplans for communication, we have added preconfigured webhooks to make setting up these integrations painless. Once configured, you can selectively manage the Assembla events that are posted out to these apps, such as ticket activity, commits, deploys, etc., to monitor project activity in real-time, inline with other team communication.

    To get started, click on the desired integration below: slack logo HipChat Logo flowdock logo Bigplans logo
    Categories: Companies

    Scrum Webinar – PMI Rome

    I had the pleasure to conduct a webinar for the PMI Rome chapter, regarding agile and the Scrum framework. This is the link to vimeo: Scrum Framework explained video (italian)  
    Categories: Blogs

    Interested in cryptocurrencies? Get started with 1000 free Ripple XRP

    Assembla Blog - Tue, 07/15/2014 - 20:55

    ripple logo

    Ripple is a protocol for value exchange that makes it easy to transfer and trade fiat currencies, Bitcoin, or XRP - the native asset of the Ripple network.

    Assembla is giving away 1000 free XRP (the Ripple native cyptocurrency) to any person with software development skills who is interested in learning about Ripple development. Get it here: https://www.assembla.com/ripple

    I called Ripple Labs a few months ago to find out more about ways that their "gateway" can help us pay developers in many different countries. Essentially, we do banking for the developers on our global team. We pay internal accounts, hold the money until they ask for it, and then transfer money to them by bank wire, ATM/Payoneer, or other mechanisms. We have found that the bank wire system is embarrassingly slow and unreliable. This is the problem that Ripple is trying to fix. Their gateway is like a bank in an open-source box. It keeps accounts in any currency, including USD, other currencies, XRP, and Bitcoin. It can transfer those accounts instantly and reliably on the shared "ledger." It is also gaining exciting new features such as "multi-signature" which enables outsourcing and crowdsourcing customers to post a budget amount, and then transfer it to their hard-working suppliers through an arbitrator.

    Now I am working more closely with Ripple to help them scale up their development process. I decided to make this free XRP offer for two reasons:

    • Users need 20 XRP to activate a Ripple wallet. We want to remove the hassle from acquiring the XRP so new developers can get started.
    • We want to build an email list of developers that might be interested in working on internal development, bounties, or bank integration projects.
    ripple blog CTA
    Categories: Companies

    Scrum Knowledge Sharing

    SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.