Product Owner sind vielen und vielem verpflichtet: Dem Kunden, dem Nutzer, dem Entwicklungsteam und der Profitabilität. In diesem Spannungsfeld auf Knopfdruck kreativ zu sein, um neue nützliche und gewinnbringende Produktideen zu schmieden, gelingt kaum einem Menschen.
Design Thinking will radikale, disruptive Neuerungen kreieren, Ideen und Potentiale sollen sich entfalten, daher benötigen Menschen und Prozess eine andere Umgebung.Der Ort für Design Thinking
Die Anforderungen an den Ort für erfolgreiches Design Thinking sind vielfältig: Ein großer Raum, eine Mischung aus Werkstatt und Wohnzimmer, mobile Einrichtungsgegenstände, große Fenster für viel Tageslicht und ein angenehmes Raumklima. Alle Wände dürfen genutzt werden, Bastelmaterial, Papier, Stifte und Getränke sind reichlich vorhanden.
Einige Studien besagen, dass die besten Ideen außerhalb der Arbeitsstätte und außerhalb der Arbeitszeit entstehen. Daher verlassen wir die angestammten Räume. Der neue Arbeitsraum ist lediglich ein Container, um die Erfahrungen, die wir mit dem Nutzer machen, zu bündeln und zu verarbeiten. Es ist der Boden, auf dem wir Ideen wachsen lassen und die kritischen Aspekte unserer Ideen in Prototypen überführen, die erneut am Nutzer getestet werden.
Im Laufe des Design-Thinking-Prozesses wird dieser Raum also gefüllt, denn Design Thinking erzeugt viele physische Ergebnisse: Mitgebrachte Artefakte, Dekorationen und natürlich Hunderte von Haftnotizen, die an Wänden und Fenstern kleben und in immer wieder neuen Sortierungen die gesammelten Erkenntnisse verdichten, bis Schmerzen und Freuden der Zielgruppe wie in einem offenen Buch vor dem Design-Thinking-Team liegen. Gearbeitet wird dabei grundsätzlich im Stehen, auch dazu gibt es Studien, die die positiven Effekte belegen. Gesessen kann in den Pausen werden – diese gibt es reichlich, da im Design Thinking mit striktem Timeboxing gearbeitet wird, um viele kurze Phasen höchster Konzentration zu erreichen.
Mobiles Mobiliar hilft dabei, den Raum jederzeit passend umzuformen: Whiteboards, Stehtische, Sofas, Regale … all dies lässt sich mit Rollen ausstatten, so dass die Sitzecke im nächsten Moment zum Prototyp eines Bahnwagens werden kann oder Arbeitsergebnisse an einer Pinnwand für den späteren Gebrauch zur Seite geschoben werden können.
Besonders wichtig ist eine breite Angebotspalette an Prototyping-Material, denn Ideen werden im Design Thinking umgehend testbar gestaltet, um sofort Nutzer-Feedback zu sammeln. Eine Anregung für Materialien finden Sie in der Checkliste am Ende dieser Seite.
Für ein konzentriertes Arbeiten ist eine ruhige Atmosphäre angenehm, dennoch soll Design Thinking nicht still sein. Lachen und klatschen ist eindeutig erwünscht, mit etwas Musik im Hintergrund lässt sich die Stimmung gut steuern.
Solch ein Raum ist keineswegs ein Garant für gute Ideen, wirkt aber in der Regel beschleunigend und unterstützend. Es gibt bereits einige große Konzerne, die an ausgewählten Standorten solche Räume installiert haben (z.B. Telekom & SAP).Frei-Räume für Design Thinking
Um den angedeuteten Raum mit einer kreativen Teamkultur füllen zu können, bedarf es einiger weiterer Zutaten:
Design Thinking wird oft als “langsam” empfunden. Besonders im Scrum-Umfeld, in dem Kunden schnelle und regelmäßige Lieferungen gewohnt sind, ist es schwierig, das Verständnis für den Zeitaufwand bei einer undefinierten Lieferung zu rechtfertigen. Es ist aber sehr wichtig, gerade in der Anfangsphase des Design-Thinking-Prozesses genügend Zeit für die “Entdeckung” zu haben, um auch Techniken wie “Cultural Probes”, “Diaries” & “Observation” einzusetzen. Ist die Zeit knapp, ist der Design Thinker versucht, lediglich ein paar Interviews zu führen und verpasst womöglich die interessantesten Einsichten über den Nutzer.
Verhalten und Regeln
Es gibt ein paar Vorgaben, um das Zusammenwirken zu vereinfachen. Es ist wichtig, dass die Teammitglieder sich an diese Regeln halten, ggf. werden sie vom Design-Thinking-Coach darauf hingewiesen. Es ist sinnvoll, diese Regeln groß ausgedruckt an verschiedenen Stellen im Raum aufzuhängen:
- Arbeite visuell
- Nur einer spricht
- Fördere verrückte Ideen
- Stelle Kritik zurück
- Quantität ist wichtig
- Bleib beim Thema
- Baue auf den Ideen anderer auf
Zugegeben, die Ansprüche an den Raum für erfolgreiches Design Thinking sind hoch.
Aber der physische Ort und der Freiraum sind gleich nach dem Design-Thinking-Team der wichtigste Erfolgsfaktor.
Suchen Sie nicht nach Gründen, warum es nicht geht. Suchen Sie lieber Wege, so viel wie möglich davon wirklich zu machen:
Verlassen Sie den angestammten Arbeitsort, gehen Sie mit Product Owner und Design-Thinking-Coach zum Kunden und treffen Sie Ihre Nutzer. Okkupieren Sie für zwei Tage einen geräumigen Eingangsbereich oder eine Lagerhalle mit viel Licht. Stellen Sie Stehtische auf und kleben Sie Packpapier an die Wände (Haftnotizen kleben gut daran). Beziehen Sie die Menschen, die fragend gucken, in Ihre Arbeit ein. Stellen Sie die Fragen und lernen Sie!
Der PO und der Kunde profitieren am Ende am meisten: Durch den Aufwand zu Beginn eines Projekts oder Release (je nach Komplexität 2 Tage bis 2 Wochen) sind die Bedürfnisse des Nutzers klar und die Lösungsansätze bereits vom Nutzer getestet. Das spart viel Zeit am Ende der Umsetzungsphase mit Scrum, da weniger nachgebessert werden muss und der Gedanke an den Nutzer durchgehend in den Köpfen präsent ist.Checkliste für einen passenden Design-Thinking-Raum
- Location: Nahe den Orten, an denen man die relevanten Nutzer treffen kann
- Raum: Genügend Platz für alle Teilnehmer, Arbeitsmaterialien, Aktivierungs-Spiele (ab 8qm pro Person, gerne mehr)
- Beleuchtung: Hell! Große Fenster und viel Tageslicht
- Luft: Gute Belüftung, Vorsicht bei Klimaanlagen: Nicht zu warm und trocken einstellen (20°-22°C genügt beim Stehen und in Bewegung)
- Akustik: Ruhig, ohne Echo
- Tische und Stühle: Stehtische (große Arbeitstische) und Barhocker/Stehstühle beflügeln die Konzentration
- Pinnwände, Whiteboards und Flipcharts: Viele davon! Leicht, mobil und magnetisch
- Nadeln & Magnete: Für die Boards
- TimeTimer: Zum visualisieren der Timebox
- Gong oder Zimbeln: Zum “Zusammenrufen”
- Laptop & Internet: Für Recherchen
- Standard Material:
- Papiere (A4 & A3 in weiß, A4 bunt & Karton, große Rollen Packpapier)
- Haftnotizen (so groß wie möglich, unterschiedliche Größen, mindestens 5 verschiedene Farben)
- Stifte (Board & Flipchart Marker, Permanent-Marker, Filzstifte in verschiedenen Farben, Bleistift) Stifte unbedingt vorher testen und Schlechte aussortieren
- Scheren, Klebeband (Malerkrepp), Locher, Klammeraffe
- Prototyping Material:
- Zeitungen und Magazine mit vielen Bildern zum ausschneiden
- Klebe (Flüssig- & Heißkleber, Klebebänder von der Rolle in transparent & farbig)
- LEGO® oder DUPLO®
- Stoffreste, Bettlaken
- Verkleidungsmaterial (Hüten, Perücken, Brillen, Schürzen etc.)
- Dicke Aluminiumfolie
Da nun im Raum alles klar ist, sehen wir uns im nächsten Teil den Design-Thinking-Prozess an. Ich freue mich über Fragen, Anregungen und Diskussionen!
- Produktfindung mit Design Thinking
- Design Thinking für Product Owner – Teil 1: Was ist eigentlich Design Thinking?
- Design Thinking für Product Owner – Teil 2: Das Design-Thinking-Team
I am a big fan of the work by Jim Benson and Tonianne Barry ever since I read their book: Personal Kanban.
In this article Jim describes an idea that I would like to highlight and expand. He says: we need a knowledge worker Gemba. He goes on to describe how to create that Gemba:
- Create a workcell for knowledge work: Where you can actually observe the team work and interact
- Make work explicit: Without being able to visualize the work in progress, you will not be able to understand the impact of certain dynamics between the team members. Also, you will miss the necessary information that will allow you to understand the obstacles to flow in the team - what prevents value from being delivered.
These are just some steps you can take right now to understand deeply how work gets done in your team, your organization or by yourself if you are an independent knowledge worker. This understanding, in turn will help you define concrete changes to the way work gets done in a way that can be measured and understood.
I've tried the same idea for my own work and described it here. How about you? What have you tried to implement to create visibility and understanding in your work?
Readiness is the beginning of the process of acclimatizing the mind toward Agile values and principles and what they really mean. It includes making decisions on the elements for your implementation. Although it is important to lead with readiness, this framework may be used iteratively depending on whether you plan for a more holistic deployment or iterative deployment of certain elements. This first starts with the premise that Agile is a culture change. The implication is that Agile is more than a change in procedure or learning a new skill. A culture change is a transformation in belief and behavior. It requires a change by more than one person, and instead by a number of people within your organization. As you can guess, this takes time.
Over the years, I’ve established what I term the Ready, Implement, Coach, and Hone (RICH) deployment framework specifically focuses on readiness activities that help you prepare not only to adopt the mechanical aspects of agile practices but more importantly, begin a meaningful transformation of behavior toward an Agile mindset.
Readiness starts the moment someone asks the question, "Is Agile right for me?” The goal is to work through this question, understand the context, and figure out how Agile might be deployed. Readiness can start weeks and even months before you really get serious about moving down the agile path. However, it can also begin when you are ready to commit.
What are some of the “readiness” activities? These activities can help you shape the implementation according to the context and need of an organization. Readiness provides us with an opportunity to:
- Assess the current environment and current state of agility
- Lay the educational groundwork of agile values and principles
- Understand and adapt to self-organizing teams and away from command and control
- Shift the focus to delivering customer value and away from an iron triangle mentality
- Discuss the agile business benefits
- Gauge the team and management willingness
Readying the mind shouldn’t be taken lightly. It is important to understand the ‘what’ and ‘why’ prior to discussing the how and when. It is important that the teams understand and really embrace the Agile values and principles. Does senior management believe in the principles? Do the teams feel they can operate in an Agile manner that aligns with the values and principles? In fact, I will dare say that if the team acts in the manner that expresses the Agile values and principles and forgoes the mechanical application of agile practices, then there is a greater chance that Agile will survive and thrive within a company.
Since there is already an overwhelming amount of material that focuses on “how to implement Agile” from a "doing" perspective, may I suggest that a different approach. Provide the time to prepare the mind toward the Agile mindset and then incorporate this mindset into the culture, education, and decision-making process for your proposed implementation. With that goal in mind, let the readiness games begin! How ready are you?
To read more about the importance of readiness and additional readiness activities in detail, consider reading the book Being Agile.
What would make a project beautiful? What sort of aesthetic would we seek? Would would make a beautiful plan? What would make a beautiful backlog? What would make a beautiful team? What would make a beautiful delivery?
I imagine it might be different for everyone…The Plan
For me, a beautiful plan would be something that covers a wall of a team or war room. It would have requirements, wireframes, architectures, acceptance criteria, impediments.
It would tell a graphic story of the evolution of the project over time. It would be a graphic history in multiple dimensions, worthy of Edward Tufte. But it would not be perfect. It would reflect rough edges, rapid sketching, mistakes, blind alleys, rough annotations everywhere.
It would also reflect the growth and improvement of the team. Items from retrospectives would be incorporated into the timeline. There would be different ways that the team measured their own performance. It would be a glorious mess!
A beautiful backlog would be on it’s own wall. It would reflect dialog with the customer, questions from the team, user profiles and scenarios.
It would be shaped like an inverted pyramid, with rich detail at the top, tapering down to sparse sets of one line ideas and proposals below. It would have color (LOTS of color) and use different shapes to indicate stories, epics, features, etc.
A beautiful team is tight. The team works physically closely together, eliminating all barriers, focusing on collaborative activity over solo activity. They work together, they eat together, they respect each other. They share roles and responsibilities promiscuously.
They pair, they mob, they swarm!
A beautiful delivery is smooth and effortless: friction free. It happens on demand – with the ease of a thought. Work flows through to production almost inevitably. It’s a downhill slide, not a grind uphill.
What does a beautiful project look like to you?
Filed under: Agile, Process, Teams Tagged: beauty, Collaboration, efficient, great projects, Process, projects
Last week I talked to one of my colleagues about a tester in his team. He told me that the tester was bored, because he had nothing to do. All the developers wrote and executed their tests themselves. Which makes sense, because the tester 2.0 tries to make the team test infected.
So what happens if every developer in the team has the Testivus? Are you still relevant on the Continuous Delivery train?
Come and join the discussion at the Open Kitchen Test Automation: Are you still relevant?
Remember the days when software testers where consulted after everything was built and released for testing. Testing was a big fat QA phase, which was a project by itself. The QA department consisted of test managers analyzing the requirements first. Logical test cases were created and were subordinated to test executors, who created physical test cases and executed them manually. Testers discovered conflicting requirements and serious issues in technical implementations. Which is good obviously. You don't want to deliver low quality software. Right?
So product releases were being delayed and the QA department documented everything in a big fat test report. And we all knew it: The QA department had to do it all over again after the next release.
I remember being a tester during those days. I always asked myself: Why am I always the last one thinking about ways to break the system? Does the developer know how easily this functionality can be broken? Does the product manager know that this requirement does not make sense at all?
Everyone hated our QA department. We were portrayed as slow, always delivering bad news and holding back the delivery cycle. But the problem was not delivering the bad news. The timing was.
The way of working needed to be changed.
We started training testers to help Agile teams deliver high quality software during development: The birth of the Tester 2.0 - The Agile Tester.
These testers master the Agile Manifesto, processes and methods that come with it. Collaboration about quality is the key here. Agile Testing is a mindset. And everyone is responsible for the quality of the product. Testers 2.0 helped teams getting (more) test infected. They thought like a researcher instead of a quality gatekeeper. They became part of the software development and delivery teams and they looked into possibilities to speed up testing efforts. So they practiced several exploratory testing techniques. Focused on reasonable and required tests, given the constraints of a sprint.
When we look back at several Agile teams having a shared understanding about Agile Testing, we saw many multidisciplinary teams becoming two separate teams: One is for developers and the other for QA / Testers.
I personally never felt comfortable in those teams. Putting testers with a group of developers is not Agile Testing. Developers still left testing for testers, and testers passively waited for developers to deploy something to be tested. At some point testers became a bottleneck again so they invested in test automation. So testers became test automators and build their own test code in a separate code base than development code. Test automators also picked tools that did not foster team responsibility. Therefore Test Automation got completely separated from product development. We found ways to help testers, test automators and developers to collaborate by improving the process. But that was treating the symptom of the problem. Developers were not taking responsibility in automated tests. And testers did not help developers designing testable software.
We want test automators and developers to become the same people.
If you want to accelerate your business you'll need to become iterative, delivering value to production as soon as possible by doing Continuous Delivery properly. So we need multidisciplinary teams to shorten feedback loops coming from different point of views.
Testers 3.0 are therefore required to accelerate the business by working in these following areas:
Requirement inspection: Building the right thing
The tester 3.0 tries to understand the business problem of requirements by describing examples. It's important to get common understanding between the business and technical context. So the tester verifies them as soon as possible and uses this as input for Test Automation and use BDD as a technique where a Human Readable Language is fostered. These testers work on automated acceptance tests as soon as possible.
Test Automation: Boosting the software delivery process
When common understanding is reached and the delivery team is ready to implement the requested feature, the tester needs programming skills to make the acceptance tests in a clean code state. The tester 3.0 uses appropriate Acceptance Test Driven Development tools (like Cucumber), which the whole team supports. But the tester keeps an eye out for better, faster and easier automated testing frameworks to support the team.
At the Xebia Craftsmanship Seminar (a couple of months ago) someone asked me if testers should learn how to write code.
I told him that no one is good at everything. But the tester 3.0 has good testing skills and enough technical baggage to write automated acceptance tests. Continuous Delivery teams have a shared responsibility and they automate all boring steps like manual test scripts, performance and security tests. It's very important to know how to automate; otherwise you'll slow down the team. You'll be treated the same as anyone else in the delivery team.
Testers 3.0 try to get developers to think about clean code and ensuring high quality code. They look into (and keep up with) popular development frameworks and address the testability of it. Even the test code is evaluated for quality attributes continuously. It needs the same love and caring as getting code into production.
Living documentation: Treating tests as specifications
At some point you'll end up with a huge set of automated tests telling you everything is fine. The tester 3.0 treats these tests as specifications and tries to create a living document, which is used for long term requirements gathering. No one will complain about these tests when they are all green and passing. The problem starts when tests start failing and no one can understand why. Testers 3.0 think about their colleague when they write a specification or test. They need to clearly specify what is being tested in a Human Readable Language.
They are used to changing requirements and specifications. And they don't make a big deal out of it. They understand that stakeholders can change their mind once a product comes alive. So the tester makes sure that important decisions made during new requirement inspections and development are stored and understood.
Relevant test results: Building quality into the process
Testers 3.0 focus on getting extreme fast feedback to determine the software quality of software products every day. Every night. Every second.
Testers want to deploy new working software features into production more often. So they do whatever it takes to build a high quality pipeline decreasing the quality feedback time during development.
Everyone in your company deserves to have confidence in the software delivery pipeline at any moment. Testers 3.0 think about how they communicate these types of feedback to the business. They provide ways to automatically report these test results about quality attributes. Testers 3.0 ask the business to define quality. Knowing everything was built right, how can they measure they've built the right thing? What do we need to measure when the product is in production?
How to stay relevant as a Tester
So what happens when all of your teammates are completely focused on high quality software using automation?
Testing does not require you to manually click, copy and paste boring scripted test steps you didn't want to do in the first place. You were hired to be skeptical about anything and make sure that all risks are addressed. It's still important to keep being a researcher for your team and test curiosity accordingly.
Besides being curious, analytical and having great communication skills, you need to learn how to code. Don't work harder. Work smarter by analyzing how you can automate all the boring checks so you'll have more time discovering other things by using your curiosity.
Since testing drives software development, and should no longer be treated as a separate phase in the development process, it's important that teams put test automation in the center of all design decisions. Because we need Test Automation to boost the software delivery by building quality sensors in every step of the process. Every day. Every night. Every second!
Do you want to discuss this topic with other Testers 3.0? Come and join the Open Kitchen: Test Automation and get on board the Continuous Delivery Train!
I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.
Some signs you may have a problem introducing a change:
- Taking action requires getting permission (this is straight from Pawel)
- Stating the desired change is too risky
- Action can’t be taken because projects are too important
- Only certain people can take action
I’m sure this could be a much longer list. The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.
Filed under: Agile, impediment, risk Tagged: culture, Impediments, mismatch, risk
This is the first look at one of our new role-based training classes. This is specifically targeted at project managers and related roles such as service delivery manager, program manager, and anyone with responsibility for delivering projects, product releases and similar batches of packaged creative or knowledge work. This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Project Management with Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.
I was flipping back over the past year and reflecting on the high-value activities that I’ve seen across various Enterprise customers. I think the high-value activities tend to be some variation of the following:
- Customer interaction (virtual, remote, connect with experts)
- Product innovation and ideation.
- Work from anywhere on any device.
- Comprehensive and cross-boundary collaboration (employees, customers, and partners.)
- Connecting with experts.
- Operational intelligence (predictive analytics, predictive maintenance)
- Cross-sell / up-sell and real-time marketing.
- Development and ALM in the Cloud.
- Protecting information and assets.
- Onboarding and enablement.
At first I was thinking of Porter’s Value Chain (Inbound Logistics, Operations, Outbound Logistics, Marketing & Sales, Services), which do help identify where the action is. Next, I was reviewing how when we drive big changes with a customer, it tends to be around changing the customer experience, or changing the employee experiences, or changing the back-office and systems experiences.
You can probably recognize how the mega-trends (Cloud, Mobile, Social, and Big Data) influence the activities above, as well as some popular trends like Consumerization of IT.High-Value Activities in the Enterprise from the Microsoft “Transforming Our Company” Memo
I also found it helpful to review the original memo from July 11, 2013 titled Transforming Our Company. Below are some of my favorite sections from the memo:
“We will engage enterprise on all sides — investing in more high-value activities for enterprise users to do their jobs; empowering people to be productive independent of their enterprise; and building new and innovative solutions for IT professionals and developers. We will also invest in ways to provide value to businesses for their interactions with their customers, building on our strong Dynamics foundation.
Specifically, we will aim to do the following:
Facilitate adoption of our devices and end-user services in enterprise settings. This means embracing consumerization of IT with the vigor we pursued in the initial adoption of PCs by end users and business in the ’90s. Our family of devices must allow people to be more productive, and for them to easily use our devices for work.
Extend our family of devices and services for enterprise high-value activities. We have unique expertise and capacity in this space.
Information assurance. Going forward this will be an area of critical importance to enterprises. We are their trusted partners in this space, and we must continue to innovate for them against a changing security and compliance landscape.
IT management. With more IT delivered as services from the cloud, the function of IT itself will be reimagined. We are best positioned to build the tools and training for that new breed of IT professional.
Big data insight. Businesses have new and expanded needs and opportunities to generate, store and use their own data and the data of the Web to better serve customers, make better decisions and design better products. As our customers’ online interactions with their customers accelerate, they generate massive amounts of data, with the cloud now offering the processing power to make sense of it. We are well-positioned to reimagine data platforms for the cloud, and help unlock insight from the data.
Customer interaction. Organizations today value most those activities that help them fully understand their customers’ needs and help them interact and communicate with them in more responsive and personalized ways. We are well-positioned to deliver services that will enable our customers to interact as never before — to help them match their prospects to the right products and services, derive the insights so they can successfully engage with them, and even help them find and create brand evangelists.
Software development. Finally, developers will continue to write the apps and sites that power the world, and integrate to solve individual problems and challenges. We will support them with the simplest turnkey way to build apps, sites and cloud services, easy integration with our products, and innovation for projects of every size.”
If you can’t imagine what high-value activities look like, or what business transformation would look like, then have a look at this video:
Nedbank was a brick-and-mortar bank that wanted to go digital and, not just catch up to the Cloud world, but leap frog into the future. According to the video description, “Nedbank initiated a program called the Integrated Channel Strategy, focusing on client centered banking experiences using Microsoft Lync. The client experience is integrated and aligned across all channels and seeks to bring about efficiencies for the bank. Video banking with Microsoft Lync gives Nedbank a competitive advantage.”
The most interesting thing about the video is not just what’s possible, but that’s it’s real and happening.
They set a new bar for the future of digital banking.You Might Also Like
For a long time now, I’ve been brute-force ugly with my error handling in my ExpressJS apps. Basically, just throw the exception after it bubbles back up to the route handler.
This works. If you don’t mind the app completely blowing chunks at this point and dumping itself entirely.
Of course, you could put a global error handler in your code to catch this unhandled exception, and *not* exit the app. But this is probably a bad idea, too. Once an exception is thrown (and not handled by the code that was being called, in the first place), the NodeJS environment is basically in an unknown and potentially bad state.Handle It Properly
Unhandled exceptions should be allowed to crash and exit the app. Therefore, you really want to handle this exception in your callback, properly.
It’s a simple change, but using “return next(err);” instead of “throw err;” allows asynchronous code to raise an exception and still have it caught by the error handling pipeline in your app. Instead of putting the app into an unknown state where everything is potential dead or dangerous, calling “next(err)” tells the Express and Connect frameworks to pass the error along until an error handling middleware of function can properly take care of it.Error Handler Middleware
If you weren’t aware of it, every ExpressJS app comes with an error handler (or two – one for development work, one for non-development work… “production” … by default) in the default app.js file that is generated by the express command line:
This code properly handles an error that was sent up the line using the “return next(err);” style of handling. Instead of putting the app in to an exception state by throwing the error, it is properly handled by the middleware, allowing you to write your own custom code, error logging and rendered view in response to the error ocurring.More On Error Handling
There are potentially a lot more advantages to doing things this way, centered around application design and code architecture. But I’ll leave those for other discussions.
If you want to read more about proper error handling, check out this article on error handling in NodeJS, from Joyent (thanks to Peter Lyons for pointing this one out):
— Peter Lyons (@focusaurus) September 6, 2014
Now if you’ll excuse me for a moment, I’ve got to go clean up some error handling code in my apps.Related Stories
The feel of silence is not the absence of noiseIn other words, although the formal definition of silence is the absence of noise, "silence" as a human experience is something different.
This reminds me of a similar phenomena with religions, for example, nominally Theravada Buddhism emphasises original, formal expression of scripture while nominally Mahayana Buddhism emphasises empirical validation and the experience of Buddhism.
In other words, instead of the formal definition of Buddhism as described in scripture, one might emphasise "Buddhism" as a human experience. The feel of Buddhism is not found in the scripture.
A relatively well-known analogy is that of a finger pointing to the moon. The point is to see and experience the moon, not the finger.
How might this apply to this thing we call Agile? Is the feel of Agile found in the Manifesto?
What is the feel of Agile as opposed to the formal definition? What is the Agile moon versus the Agile finger?
I touched on something similar when exploring Agile doctrine but in this case, let's approach things from the perspective of "feeling".
This is what I think captures the essence of the experience and feel of Agile. My attempt at a better "finger" if you will:
- Empathy and insight created by problem solvers being close to the people and situations that have the problems they're trying to solve.
- A sense of safety and confidence created by breaking down larger problems into smaller steps and validating each step.
- A general feeling of dissatisfaction leading to and reinforced by a habit of continuous improvement.
For the first time, I'm posting our curriculum for the Kanban Coaching Professional Masterclass. This new curriculum is scoped within the Modern Management Framework and takes effect in Masterclasses offered after November 1st 2014.
When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for only a few minutes. Some patterns of team disfunction are suspiciously easy to detect. But wait, here comes the trap. So you make a list, maybe write up a few recommendations and share your “gift” with the team. What team wouldn’t appreciate someone kind enough to share a list of all the ways they suck?
It doesn’t matter if you are right (and you probably are at least 50% of the time). Best case, the team thanks you for your honesty. Worst case, they kick you out of their standup and tell you never to come back. In any case, they aren’t very likely to take your suggestions seriously. The thing about impediments is, in order to really own them and take them seriously, they need to be something the team genuinely care about – and most likely they should be the team’s idea. Ownership is important, because often impediments are pretty tough to deal with, so you need to be really committed if you expect to resolve them.
Often, what I think I see are two different lists of impediments: the scrum master, coach or manager’s list, and the team’s list. The scrum master is scratching their head wondering, “How can I get these guys to engage with these impediments?” Meanwhile, the team is thinking, “Do you really want to eliminate an impediment? Fire a scrum master!”
So I guess the lesson here is that often nobody is all that interested in what you think the impediments are. They already know what the impediments are. They’re just waiting for someone to really listen.
Filed under: Agile, Coaching, Scrum, Teams Tagged: Agile, coach, Impediments, Team
Al Shalloway, CEO of Net Objectives, discusses how to apply Lean Kanban at scale to manage software initiatives more effectively. About this Webinar The essence of Kanban is to manage the workflow of value added activities by limiting how much work is being done. Al uses Lean thinking to extend Kanban to the portfolio, program, and […]
I’ve just added a high level explanation of the anatomy of the Kanban Canvas to the main Kanban Thinking site (where you can downloade the Canvas). I thought I would also post it here.System
How to assess the systemic problem and who is experiencing it.
At the centre of the Canvas is the system being worked on.
Assuming that the current situation is not perfect, and there is always room for improvement, then understanding the scope of the system helps focus on the biggest opportunities for improvement and avoids “rearranging the deck chairs on the Titanic”. By thinking about the situation as part of a holistic system, and having clarity on the scope of the system, we are more likely to identifying opportunities which improve the whole, rather than making smaller, local improvements, which might worsen the whole.
This leads to the question of what is the scope of the system. Defining the system to be too small, might not lead to any significant improvements. Equally defining the system to be too large, might be like trying to “boil the ocean”.
One way of understanding the system is to look at the people involved, and explore what problems those people are having. Narrative is an extremely useful form of doing this – finding and telling stories about people’s experiences and frustration with their work. In particular, the stories related to the customers and stakeholders will start to identify the boundaries of the system.
One fun way of exploring the system through narrative is by using the Pixar Pitch. This approach makes the final “Because of that…” refer to the current kanban system design, and the “Until Finally…” is left blank to be explored in the Impact section.Impacts
How to assess the fitness criteria in terms of flow, value and potential.
The three arrows coming out of the right of the central System are potential Impacts which might be made. These Impacts encourage a focus on what success or failure could look like, before any changes get made.
Given that in most situations, we are dealing with complex problems, where cause and effect are only apparent with hindsight and past solutions are not necessarily repeatable in the future, then we should not try to define a specific future state to solve the problem. However, that does not mean that we cannot determine the characteristics of the outcomes of solutions so we can assess their fitness criteria, or how fit for purpose a solution is.
Impact is an evaluation of fitness for purpose. A successful solution is one which has positive impact and an unsuccessful solution is what which has negative (or no) impact. Impact can be thought of as direction, as opposed to a point solution being a specific destination.
Having explored the scope of the System through narrative, we can also begin to define Impact in a similar way by asking what stories do we want to hear more of, or less off, in the future. When using the Pixar Pitch technique, imaging impossible good and bad endings to the story brings out exaggerated scenarios which can be compared against by asking whether the System is becoming more or less like the suggested endings. Getting both good and bad endings allows both positive and negative Impact to be easily imagined and identified.
When imagining the future, to create a range of diverse possibilities, the Impacts on Flow, Value and Potential are used to encourage thinking from different perspectives.Interventions
How to assess the evolutionary potential in terms of studying, sharing, stabilising, sensing and searching.
The five arrows going into the left of the System are the potential Interventions that could be made. These Interventions provide a frame for appreciating the intent behind various practices, learning and discovering which ways of working are the right ones for the current situation, and transforming those practices as the system continuously evolves.
Working through the interventions encourages continuous curiosity about which tools and techniques to use, understanding when and why they are appropriate, and ultimately collaboratively, co-creating an initial kanban system as a baseline to begin experimenting and improving.
The interventions used are to Study the context, Share the understanding, Stabilise the work, Sense the capability and Search the alternatives.
"As the e-B3-threadComputing I need to call the GarbageCollector in order to improve my memory management performance with 30%"
WOW ! When I first read a story like that I thought : "Great , this is a product about robots and this user story is about E-VE falling in love with WALL-E". As Pixar created "Toy Story", Agile Software Development invented the T-Story ( as "Technical" , of course ) . Some time after meeting the first T-Story of my life I became confused.... Because there were many of them... in all software products, regardless of the company's business that develops that software.Now, that's interesting, how come all humans in the world need exclusively products about wall-E , E-Ve and their cousins? How that did happen?!
Refactoring the Mindset My little idea is that it happened because organisations and companies treated software developers as "translation automates" of "functional requirements" in programming languages. The outcome of this mindset is a target product that is about automates . And the first version of the product risks high to leave business people speechless on a puzzle question : "How the hell did they build such an absurd product "? Well, business people, they built a robotic product that highly make little sense from an user perspective because we might have treated developers as producers of "abstractions".If we want to build products that make sense for humans, there is one think to refactor : the "automate translation" mindset. And grow a software development culture that acknowledges that software products are stories about real people .
Software Products Are Stories About HumansThe "User" side of "User Story" is the key of a great software. Gojko Adzic says that un-experienced teams create T(ethnical) -stories instead of user stories. I think is more than experience , is a question of mind set. Just shift your mind from the T-Story to a real person next to you that experiences the service you're about to implement and think about how does that feel differently. The mind shift from technical layers and composants to small pieces of code that are meaningful from a user experience perspective is hard. Nevertheless , the only way to build shippable products at the end of each sprint is to stick to this rule : every user story is a new - enhanced- experience for the user. How to do that ? If you like methods, Gojko defined the Hamburger Method . It's my favorite. Beyond the "How to" , though, the secret of succeeding is the way we think about the software protect. Because it's not a collection of code, it tells a story where human users are heroes.This is why I strongly believe software developers are writers of stories co-created together with Product Owners, Business People and whoever needs to hang around. Agile people say teams are more performant when they are collocated. If this is true it is because the fireplace where products stories are told needs to stay vivid. The software code embeds a story. Would you like the story your code tell to be awesome ?
Put makeup on your own pig, make it look as good as you can. Don’t go around finding ugly imaginary pigs to stand it beside.
Warning: This article may contain sarcasm and ranting.
Do you have a good idea about how to express something that those guys said a decade and a half ago? Well, then, just say it. You could even set it in context. Here are two ways to do it. One of them is much better than the other in my opinion.Don’t do this
“Individuals and interactions over processes and tools.” That may have been all they knew way back last century, but today we know a hell of a lot more. The real idea is to make decisions about processes and tools at the right level. Often that level is well above the pay grade of the so-called “team”. (And so on.)Instead, do this
“Individuals and interactions over processes and tools.” Here’s one way I like to work with that Agile Manifesto value. We need many tools in the doing of our work. Wherever possible, I like to let each team select its own tools and process. There is a need for consistency in a few areas, but fewer than you might think. (And so on.)What’s going on?
The first approach tries to set you up as smarter than those other guys. You’re trying to set yourself off from others, by tearing them down. Tearing down the other person doesn’t make you taller: it makes you seem small. Maybe your idea is better. Maybe you are smarter. Let your idea show how smart you are. And why set up opposition for yourself. Some people value those old ideas. Do you really want to start by telling them they’re wrong?
The second approach builds on the good things in the past. Referring to the past that way lets you associate yourself with ideas people respect, and makes your ideas seem to fit in with what people already know and care about. You reduce resistance to what you’re saying, making it easier for people to hear you.Straw Man
I often tweet reminders about the straw man from time to time, referring to this picture, entitled “Idea looking comparatively good next to a straw man.
Keep your straw man. Just tell me what you think. There is no need to quote — or more likely misquote — someone else to make your idea look better to me.Exemplum Docet – or, A Rant Begins Here
OK, that said, I’m going to put down some straw men of my own, entirely made up examples no one really said. No one would say them, I’m sure. They’re just made up examples of what not to do, because I need to rant today.
I hate those guys who push Idea X. They’re just doing it for the money. I’m glad I took the high road.
Yeah, well, intercourse you and your penguin. The people who push IdeaX mostly believe in it at least as much as you believe in … in … what is it you believe in, actually? Are you just here to whine about those other unnamed people? Is the problem really that they’re just doing it for the money, or might it be something closer to home, like regret for your own past pathetic decisions? Get over the past. Tomorrow is a new day.
Are you really satisfied with your life? If so, tell me how you managed it. Or are you jealous of someone else’s life? Keep that to yourself.
Those guys had a good idea back at the beginning of the century but what they said should be updated to what we know now.
See previous advice regarding your aquatic flightless bird. Instead of whingeing about what somebody who isn’t you did years ago, why not come up with an idea or two of your own? And instead of using your critique of those people to launch your wondrous and doubtless fascinating advice, come up with a new name.
Tell me your idea. Maybe you can even find 13 other people to help you create your marvelous new idea. Get it out there. See if it can stand the test of time.
Some people think Stupid Idea A. I teach Smart Idea B. Hahaha on those other guys. I am smarter than they are.
Where are all these fish-reeking black and white flappy creatures coming from? It’s starting to bug me. No one with even minimal credibility ever supported Stupid Idea A. You twisted the words of ten smart and sincere people to create that ridiculous idea, which is held by exactly no people anywhere. You aren’t just trying to make yourself, and your idea look good, by any chance?
Just tell me your smart idea. No need to set it up by surrounding it with stupid ideas that your readers don’t believe anyway.TL;DR
Make your own lawn look good. Stop throwing trash onto mine.
Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.
So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it
Last night we did a talk for SUGSA (the Scrum User Group of South Africa). It was a blast and full of eager learners
We spoke about 2 techniques – one to talk and understand capacity and one to assist with prioritisation. The slides are on slideshare.
If you are keen to read about more of these workshops, please buy our books!
Here is a writeup from the committee: http://sugsa.org.za/2014/09/event-report-product-owners-dealing-with-capacity-and-prioritisation/.