Wir alle kennen die Situation: Man möchte eine Herdplatte anmachen, steht jedoch vor vier Knöpfen. Welcher passt zu welcher Herdplatte? Auch nach mehreren Jahren Gebrauch kann es passieren, dass die falsche Platte angeschaltet wird. Hier bleibt das ohne ernsthafte Konsequenzen – man sieht, dass die falsche Herdplatte aufleuchtet und bemerkt den Bedienungsfehler. Was aber, wenn es es nicht um die Herdplatte, sondern um eine Herzpumpe geht?
Ein Fallbeispiel: Eine Krankenschwester wollte das Alarmsignal kurzfristig abschalten, schaltete es stattdessen aber komplett aus. Die nachfolgende Untersuchung zeigte: Der Unterschied zwischen den beiden Schaltern – einmalige versus dauerhafte Abschaltung – war für den Benutzer nicht erkennbar. Und: Der Hinweis, dass der Alarm ausgeschaltet ist, war in einer Ecke des Bildschirms als kleines Symbol versteckt und in der Informationsflut für den Benutzer schlicht untergegangen.
Die Federal Drug Administration (FDA) erhält im Jahr circa hunderttausend Incident Reports über medizintechnische Geräte. Über ein Drittel davon sind auf Benutzerfehler (user errors) zurückzuführen (Quelle: Invetech)
Wie die IEC 62366 einen Entwicklungsprozess für Gebrauchstauglichkeit beschreibt
Es ist leicht, in solchen Fällen die Schuld beim Benutzer zu suchen. Und, sicherlich: Mit einer adäquaten Schulung, einer ausführlichen Einarbeitung und einer weniger hektischen Arbeitsatmosphäre ließen sich viele Fehler im Gebrauch vermeiden. Das aber ist Verantwortung von Krankenhäusern, Praxen und Laboren. Für den Hersteller gilt: Baue ein Produkt, das Benutzerfehler so gut es geht ausschließt.
Die Norm IEC 62366 befasst sich mit der Gebrauchstauglichkeit von medizinischen Produkten. Sie beschreibt einen Entwicklungsprozess, der die Gebrauchstauglichkeit von der Erhebung der Anforderungen bis zum Testen im Blick hat. Dazu gehören folgende Schritte:
- Die Benutzerrollen des Produktes identifizieren.
- Festlegen, wie das Produkt bestimmungsgemäß gebraucht wird.
- Nutzungsszenarien beschreiben.
- Benutzerschnittstellen spezifizieren.
- Prototypen entwerfen und prüfen.
- Validierung des Gebrauchstauglichkeit.
Scrum bietet mit seinem Fokus auf den User verschiedene Möglichkeiten, die Gebrauchstauglichkeit im Entwicklungsprozess zu berücksichtigen. Hier seien zwei zentrale Elemente vorgestellt:
- Der Einsatz von so genannten Personas ist eine gute Möglichkeit, Benutzerrollen zu identifizieren. Einer unserer Kunden, der Geräte zur Laborautomatisierung herstellt, hat als eine von mehreren Personas eine 25-jährige Lab-Operator mit dem Namen María Morales. Sie nimmt die Laborproben entgegen, packt sie aus und transportiert sie ins Labor. Sie hat mittelmäßige Englisch-Kenntnisse, liest keine Benutzerhandbücher, und verlässt sich stark auf ihre Intuition. María Morales gibt es nicht wirklich, aber ihr Alter, ihre Bildung und Arbeitsweise sind repräsentativ für viele Lab-Operators. Wer solche Personas bei der Produktentwicklung im Blick hat, kann von Anfang an auf ihre Bedürfnisse eingehen und braucht erst gar nicht darauf zu hoffen, dass der Benutzer in kritischen Situationen das Handbuch zu Rate ziehen wird.
- Mit dem Review-Meeting am Ende jeden Sprints können die funktionalen Produktinkremente vom Benutzer validiert werden. Fallbeispiel: Ein Kunde entwickelt eine neue Schublade zur Aufnahme von Schalen mit Plastikspitzen, die zum Aliquotieren von Urin- oder Blutproben verwendet werden. Indem eine pharmazeutisch-technische Assistentin (PTA) zum Review der ersten Prototypen eingeladen wird, kann sie bereits die Schublade in Betrieb nehmen und mögliche Bedienungsfehler (z.B. Öffnen der Schubladen im laufenden Betrieb oder Einklemmen der Plastikspitzen) sichtbar machen.
Weitere Möglichkeiten der Validierung über das Review hinaus hat Roman Pichler hier beschrieben.
Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlag
Jamie Hartford: Human Factors: Identifying the Root causes of Use Errors
Dogs are creatures of joy. They love you, they play with you, and did I mention they love you? However, dogs can be hard to handle if you don’t groom them (definitely not letting a stinky dog into the house).
Of course when it comes to Scrum, you don’t want to let your backlog get out of hand either (yay pet metaphors!). Backlog grooming, or Product Backlog Refinement is one of Scrum’s core maintenance activities and it requires the Product Owner to regularly:
- Rank the backlog items
- Add details to items (description, estimates, etc)
- Add and promote items
- Remove and demote items
- Break larger items down
- Combine small items into larger items
The Axosoft Scrum tool makes it easy to accomplish all of these tasks (especially if you’re already familiar with adding and editing items), but for the rest of this post, let’s focus on ranking. To rank items, click on this down arrow here in the main toolbar after you’ve created your backlog items.
Once this is done, your Product Owner will be taken to Rank View, which allows him or her to stack rank all the items. This is done by dragging-and-dropping the more important items toward the top, while unranking items that bear less significance. Pretty easy, right?
But what if you’ve broken down an item into several subitems? Well, you can also rank the sub-items against each other and right click to remove any unnecessary tasks. If you have numerous items, it’s easiest to start by filtering down your view, so only the items you need are revealed. For example, you probably don’t need to see items that are closed or items that are already assigned to the current sprint. Although every user may not have permission to rank items, they will have the ability to sort their view by rank by clicking on this icon in the toolbar.
Once the order is set, just drag and drop the selected items over to your next release or sprint. When you’re selecting which items to assign into a sprint, keep a few things in mind:
- Sprint items should each carry some measure of business value.
- Your team must be able to complete each item during a single sprint.
- Expectations and a ‘definition of done’ should be clearer than the glistening waters of the Caribbean.
We don’t want folks barking about your backlog, so hopefully these tips will help you keep it on a leash. For more information about shortcuts check this post, or find us on Youtube to get an overview of the product. Woof woof, Axodog!
My goal is that each project I work on should be the best project I ever worked on. Each project should achieve great results. Scrum helps me achieve both goals.
What follows is my view of Scrum. It is the vision I try to pass on in my courses and the vision I try to live in my own projects. I hope it is also the start of an interesting conversation!
Introduction - What is Scrum?Scrum is a simple, team-based framework for solving complex problems. Scrum is a framework for transforming your working environment into a much better place. Scrum is a mindset.
The core of Scrum can be summarized in two words: Inspect and Adapt. The roles, activities, agreements and instruments defined in Scrum exist to enable inspection and adaptation at regular intervals on the basis of correct and honest information.
To adapt means to change for the better. So Scrum is not simply a framework for building great products, it is a framework for transforming your environment into something better. A willingness to change is essential for success with Scrum.
There are many issues that Scrum does not address. Scrum does not tell you how to develop software (or solve any other problem area). Scrum does not say anything about the structure of your organization beyond the Scrum Team. Scrum does not tell you who answers the phone when the customer calls.
What does Scrum help you do?Scrum does help you recognize issues quickly. Resolving them is your job. How to solve those issues? Those pages are left blank, so you can develop, adapt or evolve great approaches to fit your context. And there are many practices, from Extreme Programming, Lean Thinking and Kanban, to Radical Management, Management 3.0 and Lean Startup, to name but a few, that can help you in your situation.
Through its simple framework, Scrum helps you eliminate the common sources of dysfunction in projects. In particular, excessive multitasking, too much work in progress, and unrealistic expectations can be hugely detrimental to your performance. Scrum enables you to create an environment that values focus, finished work, a sustainable pace and true collaboration.
Scrum is a reference implementation. A reference implementation can be a good place to start, because it is known to work effectively. It’s also a reference for evaluating your own approach and its effectiveness. Is pure Scrum “by the book” the only way to inspect and adapt effectively? Of course not! Is the best way? There is no single best way. But if your approach has you inspecting and adapting less often than Scrum, you are probably less effective than you could be.
So as you practice Scrum, sooner or later your approach will evolve away from Scrum by the book. That's OK, as long as your changes are genuine improvements, that is, they cause you to inspect and adapt more often.
My last few months of working with a larger, more traditional organisation has lead me to conclude that the roles and processes involved in traditional project management only serve to get in the way of creating something meaningful.
I’m sure I could deliver so much more for them, with less risk, without the big plan, estimates, project managers, deadlines or a hierarchy. Whilst this conclusion is driven by frustration rather than anything more rational, I’d feel a fraud if I couldn’t suggest an alternative. So it begs the question…What do I need? A shared purpose
We’ll invite anyone who cares and ask “What do we want to change?”A diverse mix of curious people
If we Invite people for what they know and we’ll get the same thing that they built last time. Invite them for their curiosity and they’ll learn the new skills we really need.Foundations
They’ll be a set of skills we’ll need to get started. We’ll invite Designers, Engineers, Business People who understand the challenges.Space
We’ll need a place to create that we can call our own.And what could we do? Create
Without the distractions this can be our main focus.Collaborate
Pair, mob, self organise – let purpose be our leader. We’ll know we’ve got this right when a supportive, challenging, appreciative culture emerges.Take one step at a time
Please stop trying to predict all the things we’re going to need; We’ll build the next most important thing, use it and then decide what comes next. We’ll rigorously call out untested assumptions and test them before we move on. We’ll keep options open and feedback loops tiny.Build capability
Through continual improvement, reflection and a focus on learning, we can build our capability whilst staying small and nimble.Release
Abandon fixed scope or fixed time and big releases. We’ll release every day and you’ll adopt when you see the value.Keep learning, keep releasing
It’s never done, theres no end, only evolution and revolution.
Can this be done instead of a traditional “Enterprise Project”? Anyone want to try?
Hey everyone… not sure how many of you actually visit our site vs. keeping up with RSS… but if you’ve had a chance to visit leadingagile.com in the last few weeks, you’ll notice some pretty significant changes. This is the third major revision since I started the blog 8 years ago… and really the first time we’ve had anything professionally done that could reasonably be considered a full-blown company website.
Due to my schedule over the past year… it has taken forever to get this first cut out. We definitely did not eat our own dogfood. This was not an agile exercise and definitely not iterative and incremental… but that is about to change. We’ve got sections built into the site for all our major framework stuff, what we offer as a company, who we have on board, and of course… our blog and other thought pieces.
My intent is to start spending some time filling in the blanks and hardening up what’s already there. If you’re interested in this kind of stuff, please take a look and let me know what you think. Your feedback is welcome. We are learning by doing and our approach to transformation is evolving so fast it’s difficult to keep up. It’s even hard to keep everyone on the team up to speed with how things are evolving.
Hope you enjoy what you see so far and we look forward to engaging with you in the comments!
CERTIFIED KANBAN ADVANCED PRACTITIONER TRAINING This Advanced Kanban Practitioner training teaches advanced principles of the Kanban Method. It is for people who have already mastered the Kanban basics and want to learn more. This is a certified Kanban training course and it follows the high quality standards of the Lean Kanban University (edu.leankanban.com) and is conducted in cooperation […]
How to deliver more value faster? I’m constantly thinking about speed in software development. This article is a result of my thoughts. I built a model that describes all obvious and complex dependencies between software development practices and briefly analysed this model. I hope you will find something new and enjoy the read.
“Every single CEO of any IT company wants to build software faster. Time is the most expensive and valuable resource. You can’t waste it on re-work, refactoring, meetings, physical activities. Right? It depends…”
As a "creative" i.e. a designer of things and ideas, not software, is it possible to come to great results that fulfils wishes, excites and comes to market quickly even under the atmosphere of big uncertainty that is characteristic for creative projects?
As a creative, you know the answer has to be "Yes!" Are the approaches that you are using to manage and plan work, create ideas, collaborate with the customer to make the ideas even more awesome, are these practices effective? If you have watched an episode of Mad Men, you know the answer is "No!" Want to find a better way?
Learn, explore and find a better way with leaders!We are a small team consisting of Design Manager Sandra Islam, Roland Sailer, a partner of the branding agency NOSE, and Peter Stevens. We believe something like Agile and Scrum is going to become the standard approach for creatives.
Software development is a complex and creative process, which is often poorly understood by those asking for software products. Sound familiar? "Agile" "Scrum" and "Lean" values, principles and practices have enabled software developers to become more creative, more effective and have more fun at work. They have been the basis for everything from more efficient manufacturing processes to more effective organizational transformations.
Can they help creatives do the same? We think so! We are looking for a few pioneers to explore Scrum, Lean and Agile with us, to create new and better ways of working in a creative context.
Here's the plan
- June 14/15: Learn about Scrum - you'll become a Certified Scrum Master in this course in which we'll take a special look at the needs of Creatives who are not doing software.
- June 25: Take it to the next level - Scrum and Agile work in software, but the work of creatives is different. How do you tackle the challenges of a creative environment? This is a one day workshop, not a course, and not a PowerPoint binge! We'll identify the challenges together and come up with solutions together, so you can start improving your environment right away!
- Contact me to ask about special pricing (or other questions)
- Register for the Weekend CSM Course with Creatives Workshop!
- Get ready for the Red Pill!
If you’ve been to Asian countries, or to Chinese quarters in a large city, you probably know that they eat bugs in Asia. Well, they also eat snakes, caterpillars, ants, worms and what not, but for the sake of my today’s discourse I’ll focus on bugs. Cooking and serving bugs properly is a high art. If something in the cooking process is messed up, bugs will not taste as a deli, but as something mmm… extremely un-delicious. I don’t think I will ever want to eat any of those many-legged sources of protein, unless under very compelling circumstances. However, there are folks who have to deal with bugs every day. In office. At work. You guessed it right. Today I will sum up a few tips on how bugs should be cooked and served for QA engineers, or for anyone else in your team who wants to digest them and to get rid of them as efficiently as they can.
I’ve borrowed these tips from our QA team. Actually, I need decent bug reports in my work as a publishing editor of Targetprocess product blog release notes as well. These release notes include a short summary of fixed bugs, and at times it’s been quite a pain for our blog publishing team to understand what those bugs are about from their names. For the release notes, we want bugs to have concise names, because our customers need to know what we actually fixed. Likewise, developers might experience the same kind of trouble, trying to retrieve the nuggets of meaning from a lousy bug report in their daily assignments. Or, support engineers need to check quickly if a bug they’re reporting is known, or not.Why do we need informative bug reports?
a) We waste no time asking myriad questions trying to figure what a bug description implies. Yes, in agile teams people are supposed to talk. However, when a team gets bigger, approaching someone and talking might not be as simple as in a pizza-sized team.
b) We can quickly refresh in our memory what exactly has been done about that bug.
c) We are able to follow the thinking behind a bug fix solution, and we stay informed of any possible trade offs, if any, and why they have been made. At times, the steps to reproduce a bug, or a bug fix might seem weird, unless one knows from which pantry this bug comes from, so to say.
d) To stay in the loop of what’s going on around and make mental notes of the bugs processed by other teams.
Now, can anyone, except the person who wrote this, figure what the following is supposed to mean: “This thing is not working correctly” ??? To make some sense of it, one has to check probably tons of info searching for a clue of what “working correctly” implies for “this thing”.
On top of that, if this bug lacks a screenshot and a clear how-should-it-work summary, the person who posted it looks like a perfect nominee for the “Bug Chef Dunce” award.Which bug is a well-served bug?
We will call bugs well-served if all of the following is true:
1. Their Name is a concise, well-written sentence that renders the problem. Not that this bug just exists, not where it exists, but the problem that it causes to users.
Compare: “Quick Add for users is not working correctly” and “Quick Add many users: only the first user from the batch is assigned to selected Projects”.
2. A good bug Summary should allow a developer to understand in as little time as possible which behavior should be reproduced and the steps to reproduce it.
Bugs with a summary such as this one — “When I see “remove” button, I see performance degradation” — get straight to hell along with the “wordsmiths” who write them. One might want to use the “What? Where? When?” technique to write a bug summary. What goes wrong, where this wrong behavior is observed, and when, at which actions.
3. Actual behavior vs. Expected behavior. A few sentences or screenshots describing these are the best friends of productivity for a fix. They simply leave no chance for your bug report to be misunderstood and fixed improperly.
I hope this quick tips will help QAs, developers and tech support teams ensure that their bugs are served properly, ready to be digested by stomachs of whichever omnivores who need to process them.
“Agile is not a Process – it Defines a Culture”
- The Top Five Agile Methodology PPTs | by LeadingAgile http://t.co/nCy9928LsB
- 17 Things You Should Give Up in Order to Be Agile – by Tony Khuon http://t.co/vJoBAjZfq9
- Software Development Today: Why processes fail us, and what to do about it http://t.co/YZkBP0gKD2
- What’s wrong with Software Development? | Markus Gärtner http://t.co/mqlvt0nsvF
- The Impact of Agile Quantified – videos from Rally Software http://t.co/dr4be4RsGT
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!
Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.
I once worked for a manager who thought everyone should bow down and kiss his feet. Okay, I’m not sure if he actually thought that, but that’s how it felt to me. He regularly canceled his one-on-ones with me. He interrupted me when I spoke at meetings. He tried to tell the people in my group what to do. (I put a stop to that, pretty darn quick.)
He undermined my self-confidence and everything I tried to accomplish in my organization.
When I realized what was going on, I gathered my managers. At the time, I was a Director of Many Things. I said, “Our VP is very busy. I think he has too many things on his plate. Here is what I would like to do. If he interrupts your work with a request, politely acknowledge him, and say, “Johanna will put that in our queue. She is managing our project portfolio.” If he interrupts you in a meeting, feel free to manage him the same way you manage me.” That got a laugh. “I am working with him on some customer issues, and I hope to resolve them soon.”
My managers and project managers kept on track with their work. We finished our deliverables, which was key to our success as an organization.
My relationship with my manager however, deteriorated even further. In three months, he canceled every single one-on-one. He was rude to me in every public meeting. I started looking for a new job.
I found a new job, and left my two week notice on his desk. He ran down the hall, swept into my office and slammed the door. He slammed my notice on my desk and yelled at me, “I don’t accept this! You can’t do this to me. You can’t leave. You’re the only director here accomplishing anything.”
I said, “Are you ready to have a one-on-one now?”
He said, “No. I’m busy. I’m too busy for a one-on-one.”
I said, “I’m leaving. We have nothing to discuss. You can put your head in the sand and try to not accept my resignation. Or, we can make my last two weeks here useful. What would you like?”
“You’re not done with me, Rothman!”
He stalked out of my office, and slammed the door on his way out. I got up and opened the door. I was never so happy to leave a job in my entire life.
Some managers don’t realize that they are not their title. Some managers don’t realize that the value they bring is the plus: the management, plus their relationship with their peers, the people they manage, the systems and environment they enable/create. This guy had created an environment of distrust.
That’s what this month’s management myth is all about: believing that I am More Valuable Than Other People.
If you are a manager, you do provide a valuable service: servant leadership. Make sure you do so.
There are lots of little things that can boost your experience within Axosoft. Today we’ll talk about this little triangle.
You’ll see this right triangle with all its 45-45 degree glory in the black column header and you will also see it when you create subitems. There are three different settings for this little guy and we’ll briefly breakdown each one.
If the triangle points to the right, then you will hide all your subitems. This one is the easiest to figure out. You can do this locally for each parent item or you can set it for all the items in view by changing the triangle in the main header.
Points to the Lower Right:
The next one gets a little tricky. If the triangle points to the lower right (and it will have this tiny hole in the center of it), then you’re telling Axosoft to only show the subitems that match your filter. If I have my name selected under users for example, this setting is a great way of only seeing subitems assigned to you.
And of course, this one will reveal all subitems. It was really that second one that you should try to use more.
There you have it! You now have the knowledge to streamline your viewing and filtering even further. Be on the lookout for more tips to come and check out some other useful shortcuts here.
Als ich vor ein paar Wochen die Informationen über meinen neuen Consulting-Auftrag bekam, war ich gespannt und neugierig zugleich. Erstmals ging es für mich um ein Projekt, das im ERP-System (Enterprise Resource Planning) von SAP angesiedelt war.
Neben einer Weiterentwicklung der hausinternen ABAP-Eigenentwicklung (Advanced Business Application Programming) sollten auch diverse Anpassungen in einem SAP-Standardmodul umgesetzt werden. Letzteres beinhaltet zu großen Anteilen das sogenannte „SAP Customizing“. In diesem Prozess wird das SAP Standardmodul durch einen SAP Berater mit Hilfe von Konfigurationen auf die im Unternehmen eingesetzten Geschäftsprozesse angepasst. Dabei werden die Berater von Entwicklern unterstützt, um etwaige Sonderfunktionalitäten im Standardmodul abzubilden, die nicht mit Hilfe des Customizings realisiert werden können.
Die Vorgehensweise des SAP Customizings ist in vielen Unternehmen typisch klassisch nach einer Wasserfallmethodik ausgerichtet. In einem ersten Schritt wird basierend auf dem Anforderungskatalog ein Konzept entwickelt, indem die Datenstrukturen und deren Verknüpfungen über Masken und Dialoge festgelegt werden. Anschließend werden in der Umsetzungsphase diese Datenstrukturen erstellt und das Standardmodul so angepasst, dass es den Geschäftsprozessen des Unternehmens entspricht.
Die ersten Sprints
Die ersten agilen Iterationen gestalteten sich als äußerst schwierig. Das fehlende Konzept verunsicherte Einzelne der SAP Berater, da sie stets das Gefühl hatten, das SAP Standardmodul im „Blindflug“ zu customizen. Auch die vielen Veränderungen basierend auf dem Feedback des Kunden führten zu Unmut, da Datenstrukturen wiederholt angepasst werden mussten. Den Satz „Das wäre uns mit einem Konzept nicht passiert“ hörte ich unzählige Male. Die Frage, die sich mir stets stellte, war, ob es in früheren Projekten nie zu Change Requests gekommen war? Die Antwort war, dass diese sehr wohl Bestandteil der Projekte waren, aber nicht mit der Häufigkeit wie in agilen Projekten auftraten. So weit so gut, wir beschlossen, die agile Methode einfach durchzuziehen.
Der Kunde war bereits nach den ersten Sprints hochzufrieden mit den Lieferungen des Projektteams. Noch nie zuvor war es ihm möglich gewesen, bereits nach dem ersten Sprint ein vorführbares Ergebnis zu sehen. Es konnte doch tatsächlich ein gesamter Geschäftsprozess durchgespielt werden; auch wenn dieser großteils noch manuell zu bewerkstelligen war und erst in den Folgesprints automatisiert wurde.
Die SAP Berater, angesprochen auf die Erfolge mit der Kundenzufriedenheit, räumten nach ein paar Sprints ein, dass sie immer noch Schwierigkeiten mit der neuen Methode hätten und dass sie „ihr“ Konzept vermissten. Sie sahen sich aber auch mit der Tatsache konfrontiert, dass sie die Einzigen waren, die ihr Konzept vermissten. Für den Kunden, der in früheren Projekten ursprünglich das Konzept vor der Umsetzung absegnete, war das Fehlen eines Konzeptes nicht weiter tragisch. Zumeist hatte er das Konzept ohnehin nicht vollständig verstanden und mit der neuen Methoden konnte er nach ein paar Wochen nicht nur einen Stapel Papier, sondern schon Teile seiner Endlösung sehen.
Der Erfolg des Projektes zeigt, dass auch ERP-basierte Projekte, wie jenes mit SAP, agil entwickelt werden können, ganz gleich, ob es um Programmierung oder Customizing handelt. Es geht in jedem Fall um die Schaffung neuer Funktionalität, um die Entwicklung eines neuen „Produktes“. Wie immer in solchen Prozessen hilft die iterative Vorgehensweise, den Kunden schneller zu beliefern und insgesamt zufriedener zu machen.
- In Scrum we trust?
- 3. Deutschsprachige Scrum Gathering
- Scrum & das Team – Rückblick auf den ScrumDay in München
The more I explore how IT organizations work, the more I see how strikingly diverse they are. They are as unique as human beings. Each organization has its unique process, unique culture and unique service or product that they deliver. On the surface, it might seem that businesses can be broken down into categories, e.g. a small or a large, a production or a service company, and there’s indeed a certain similarity. The big “but” comes into play when an organization wants to achieve some outstanding goal, e.g. increase sales by 300%, or cut down the time to production by 50%. There’s no such thing as similarity then. Small things in which companies differ then gain the last-drop power for a breakthrough to happen. The uniqueness lies in custom mixes of organizational culture and production process. Unique goals require unique ways to achieve them. I will use software development industry as an example to illustrate one striking phenomenon that holds they key, the Holy Grail to getting things done efficiently in unique organizational contexts.Solve a Unique Problem by Copy-Pasting a Solution? No way.
At various phases of their lifecycles, organizations have to address their unique challenges. What do stakeholders usually do first as they encounter a problem? One disturbing commonplace trend that I’ve noticed is to replace addressing the root of a problem with a trendy buzzword model or management technique, and rely on it thinking: “Once we implement this super thing in our company, all our problems will be resolved.” Or, if the Super A..buzzword technique is implemented, and brings no results, stakeholders keep staying in the limited stalls of prescribed buzzwords, and then that’s what they think: “Hmm, the Super A.. thing is not working. How about we try a Super K… thing?” I’ve written about that in my previous articles on agile, Kanban and Big Data, as I looked at their origin, and on how they play out in the long run. It could all be very well if this approach with sticking, or switching, to one coined technique or another helped in 100% of cases. That’s not true, however. It seems that most organizations have slid from the ruthless clarity of a simple “why?” to juggling boxes filled with loud labels for what some time worked for someone. Thinking is the hardest job, and with the amount of cognitive loads that we, Homo Sapiens, experience these days, organizational stakeholders are tempted to use shortcuts and grab the leash of what a mega-guru has said should be done. *Totally forgetting that the mega guru probably used this technique or a tip for an organization that is completely different from yours*.
Which consequences does this habit have on a larger scale? Trying to fit a unique context of an organizational challenge to a limited set of Super A.. or Super K… techniques is an attempt in futility. If there’s some fat on the belly, that is, if this organization can afford paying for such abstract things as “measuring agility” (???), then the stakeholders would hire a consultant to translate the language of how things work in their organization to a lingo of a Super A.. technique, and/or will send their employees to be certified in this new religion, and/or introduce some ridiculous measurements that would serve it. Such reality shows are ubiquitous, and the following lame syllogism crowns them: “We are going Super A.. now, so we need a tool to call ourselves truly Super A…” or ” Hmmm… Super A.. does not work for us. The sales are not higher, and we do not have faster turnaround times, and Super A… is not helping us find out if what we are doing is actually right or wrong for our organization if we want to hit this target. Hmm. They now say a lot about the Super K.. technique. Yes! Let’s try it. Let’s switch to Super K.. and, of course, we want to be truly Super K.. so we need a tool for that!”
No comments.The Health Check: 5 Why’s and 6 W’s
The quickest health check is to ask the 5 Why’s. Why are we doing this? If the name of the Super A.. will still linger in the answer to your very last 5th “why”, you can probably throw the super A.. to the trash bin. Your organization needs to deal with real things. Not with the labels in a toy store. The other health check is the 6 W questions technique (What? Why? Where? Who? When? Which?) applied to what you have in plan for projects and processes. As a side note, I don’t care from which buzz management Super XYZ lingo the 6 W’s and 5 Why’s originate (and, yes, I do know of Six Sigma). These are the simplest bulls..it detectors to verify the actual worth of an approach to management.
It breaks my heart to read articles and blogs on software development written exactly with the Super Whatever shallow mindset. I can’t stand looking at how limited thinking prevents people from grasping the uniqueness of their challenges and addressing them effectively. I can’t stand looking at how the loud name of “methodology” is haphazardly glued to the how-to techniques and practices that worked only for certain organizations. And, I’ve explored the reasons for that thing happening in one of my previous articles. The education that IT professionals receive is too narrow. It doesn’t allow them to look beyond how-to’s too much, as they are not even trained to look beyond the how-to’s. The how-to approach works for coding, or for dealing with mechanisms, but it doesn’t work for organization/product/project management. I’m humbly hoping that my articles help to provide broader and deeper perspective, a perspective that someone might need to fix things gone wrong in their organizations.
Back to my intolerance to the evil reign of how-to’s and to the habit of their copy-pasting. This habit is even more dangerous than smoking or drinking, because with these everyone knows they are bad habits, while with the how-to’s abuse, people keep thinking that if everyone else does it, then that’s OK.Pragmatism is Dead, Long Live Pragmatism!
It’s time to regain justice and call things their true names. Let’s retrieve one precious treasure from the chest of eternal wisdom and blow the dust off of it. The treasure that lies there abandoned has this written on its plate:
A methodology is a school of thought, and a method is a way of doing something.
In other words, practice is the only criterion for truth. On the meta-level, this reasoning is backed up by the philosophy of pragmatism. However, there can be a shallow pragmatism and a smart pragmatism. A shallow pragmatism, briefly, is a short-sighted plan and course of actions, while smart pragmatism is something that I’ve written about in the article Visualization: Why the Fusion of Arts and Tech Matters.
The smart pragmatism, for software development, occurs when the blind sages touching various parts of an elephant recover their sight and realize that all of its parts function as a whole. Often organizations held their internal mini-wars, especially as they grow, between marketing teams and production teams, as they divide the spheres of responsibility between many decision-making groups, and when those parts have to merge, it feels like flying through the rough air. The head does not know what legs and arms are doing, something of that nature.
I want to make null and void any methodologies except “use your guts”. There’s no such thing as a success of a one part. Success comes as a whole, and for that success to happen, unfortunately (or fortunately), there’s no other way as to think outside-the-box, sometimes even forcefully blocking the trendy how-to’s. One can read tons of books, or follow gurus, or “best practices”, but these activities are secondary as compared to independent thinking. Sometimes, it’s a surprising and a pleasant side-effect to discover that you have arrived to the same conclusion as some renowned guru did, but by yourself, in your practical context. And this is a lot more precious and effective than copy-pasting a technique with no deeper understanding. That’s why, if you have no guts — grow them. If you have guts, but you’re too tired, get some rest and restore your ability to think independently and clearly.No Need for Ninjas, but Let’s Call This Thing Somehow
The use-your-guts pragmatic methodology does require a method (a way of doing). I’ve checked on most of the methods used in software development. Some of them have common sense in-mixed with limiting prescribed practices (see my article Stuck with Kanban? Consider Multiban). As you might have guessed, I have invented a method that is based on Kanban, but differentiates from it in the core “way of doing “. And, although I’m quite skeptical about using new names for what appears to be clear, I still have a name for that method: Multiban. This word is a Japanese-English mixture, and means something along the lines of many boards, many views and many perspectives. This name will stick in the memory, as it implies connection with Kanban method, with one important update. While Kanban uses cards as static signs for work items only, Multiban uses cards as dynamic signs for any abstract or concrete entity. Multiban is a visual management method (see and use your guts) that has no prescribed practices. All Multiban wants are custom visual representations, multiple 2D views of crossed rows and columns, that support whichever perspective to power your thinking. Why I deemed Kanban a good method to build on further? It’s because of the “visualize” part. That’s about the only thing that is unquestionable about the Kanban method: visualization. Nothing else supports the pragmatic, use-your-guts thinking better than visualizing. Indeed, when things are brought from heads to paper (or to screens), that’s a huge aide. Pragmatic stakeholders need more ways to look at what happens with their projects and processes, than with static Kanban cards that signify work items.
Now, as I’ve identified this method, for free-thinkers who want unlimited help and unlimited freedom with their unique ways of thinking, let’s see which digital tools might support this. Most of the Kanban tools are limiting. They lack versatile visualizations. Here’s a write-up about one such pretty decent Kanban tool that, however, fails to deliver many views and many perspectives. Quite predictable, I found out that so far only Targetprocess 3, our visual management software, supports the unlimited thinking and free-from-the-leash no-nonsense work — and the Multiban method — as it brings to the table unlimited 2D views for any dataset. No strings attached, the tool also allows to exercise agile, Scrum, Kanban and other SUPER ABC things. But the most important part about Targetprocess 3 is that it supports your own unique way of thinking and decision-making, be it on micro-level with bug fixing, or work items management, or on macro-level with managing portfolios of projects, or with roadmaps, in ERP or wherever.
I’m probably trying to squeeze too many things in one article. Each of the aspects I’ve touched upon deserves an article by itself. I’m certain that what this world lacks most is insightful out-of-the-box thinking. People are stuck in prescribed patterns on many levels in their lives, their work in software development, or organization/product/project management being one of them. I want to tackle this, and that’s why I will persistently champion the smart pragmatism and the Multiban method in my writings.
If you want to learn more about how Multiban stands out as a method and as a technique for visual management, check the related articles.
Lynn Winterboer - (@agilelynn) With a proven background in a variety of data projects and agile practices, Lynn Winterboer teaches and coaches DW/BI teams on how to effectively apply agile principles and practices to their work. For almost 20 years, Lynn has served in numerous roles within the analytics, business intelligence and data warehousing space. She has worked in numerous industries, including insurance, banking, retail, energy, high-tech manufacturing and channels, telecommunications, education, internet security, web marketing, government and healthcare. Lynn very well understands the unique set of challenges faced by DW/BI teams who want to benefit from the incremental style of Agile development; Lynn leverages her experience and training to help deliver practical solutions for her clients and students.
I have noticed a recent increase in the number of recruiters contacting me for Product Owner roles, many of them looking for someone to work with a data-focused team (my area of expertise). I just chatted with a recruiter looking for an experienced product owner (PO) to work with a healthcare company’s analytics team in the Denver Tech Center area. (Know anyone?) We both bemoaned the fact that there aren’t many experienced POs available in the market, much less any who have a good background in working with data warehousing/business intelligence/analytics. I can imagine other teams struggle to find product owners with the right amount of experience in their industry or business function.
If you are looking to hire product owners for your analytics team, and can’t find the perfect person on the market, I have an idea for you.
Step 1: Find someone who has the right experience as an analytics business analyst and WANTS to work in an Agile framework:Focus Why Eliciting business requirements for BI/DW/Analytics projects. One must know how to ask the right questions and capture the right information related to DATA projects (which can be different than requirements for workflow, web or mobile projects!) Business process analysis: How the inputs, actions, and outputs of each step in a process add to (or inhibit) the value the organization gets from the process. Product Ownership is all about understanding, articulating, and prioritizing the VALUE each piece of work brings to the organization. Solid experience working with data One needs some good, healthy scar tissue from wrangling with data in order to understand the challenges faced by the delivery team members and work collaboratively with them REALLY good relationship skills across all business functions, from accounting to sales Product Owners for BI teams often need to support multiple functions in the business. Therefore, a PO has to facilitate and negotiate priorities across these various functions. (See “BI Product Owners Love an Agile PMO!” for more on this) Natural tendency toward, and desire to learn more about, agile practices: Focuses on team success over personal glory, loves to learn and grow regularly, comfortable with change, already knows agile is a MUST HAVE in future career choices! Agile is not for everyone. There are places where traditionalists would be happier than on an Agile team. Agile is simple in concept and difficult in execution. One has to have a deep passion and drive to live the agile values and principles or it just won’t work.
STEP 2: Train, mentor and coach this person to work within an Agile framework:Topic Why What is “Agile”? One needs to understand the background, tenets, and various approaches of the Agile movement in order to have a strong foundation to stand on. Throughout a product owner’s career, it is very helpful when in doubt to go back and review the Agile values and principles, and figure out how to align with them. How do DW/BI/Analytics projects work within an agile framework? The data world has some additional challenges to working within an Agile framework that other IT groups don’t. There are also ways in which an agile approach is a better fit for data teams. It’s important to understand these differences so the PO can be a healthy participant in the delivery process. How does a Product Owner build a roadmap based on prioritized projects and capabilities? This is where a PO’s experience in cross-functional relationships and business process analysis comes in handy. The Product Owner seeks out and takes multiple viewpoints into account, assesses organizational value for each opportunity, and decides the order in which the delivery team should focus on each project/capability. The agile world has lots of good practices available for POs to use in prioritizing and building a roadmap. How does an agile team initiate a project? The PO is responsible for creating a project vision and motivating involved folks to quickly deliver organizational value. It’s a big job! Fortunately, there are agile practices that make this a community event where everyone leaves with a common understanding of, and excitement for, a new project. This allows the delivery team to be much more autonomous in figuring out the best way to deliver the desired product – which leads to better code as well! How does the Product Owner write, prioritize and groom user stories? The Product Owner has a big responsibility – to make sure the team is building the RIGHT THING (while the team focused on building the THING RIGHT). Without this leadership, a team can quickly iterate in the wrong direction and fail to deliver value – even with perfect code. Most of the user story classes and examples available to Product Owners today are based on web or mobile projects, and it can be difficult for a new PO to “translate” that guidance into something useful for a data-focused team. Training and mentoring on user stories for analytics teams shortens the learning curve and reduces false starts. How does the PO know when to accept a story as “done”? A key method for making sure the user stories are clear for the team is to include detailed acceptance criteria for each story – possibly even to the point of articulating the tests that would need to pass to “prove” the story is complete. This takes a lot of work, and is critical for the PO to reduce wasted team effort (building the wrong thing due to misunderstanding) and creating faster value for the organization.
In my experience, it’s more difficult to teach somebody about the nuances of the data world (this often takes years of hard-won experience to really understand), than it is to teach them about the Agile approach. The main reason is that Agile is a journey and the community is supportive of “newbies” with the right attitude who want to continuously learn and grow. One of the key tenets of ALL agile frameworks is a regular and frequent “inspect and adapt” process (often called retrospection) that allows participants to learn from their mistakes and do it differently next time. It’s a wonderful situation for someone learning something new!