It was time for an update.

Here’s my Focus Checklist v2:

Focus Checklist (v2)

Here’s what’s new …

I organized the checklist into more meaningful buckets.   It’s mostly the original list, but now they are grouped into better buckets to make it easier to turn into action.  After all, a great checklist is measured both by it’s value and how actionable it is.

Focus is often the different that makes the difference when it comes to succeeding at work and succeeding in life.   Otherwise, we don’t see things to fruition, or we bi-furcate our potential in ways that undermines our effort.

To make it easy to get to the Focus Checklist, I added a quick menu item to the feature menu:

You can still get to the checklists from Resources, but the saying “out of sight, out of mind”, tends to be true.

By moving Checklists to the feature bar, it will remind me to continue to turn insight into action in the form of simple checklists.

I’ve long been a fan of checklists for building better habits and sharing and scaling expertise.   I’ve used them for security, performance, application architecture, and for personal effectiveness in a variety of ways.   There’s actually a lot of research and science behind why checklists are effective, but I like to think of them as simple reminders and automation for the mind, so we can move up the mental stack and focus on higher-level issues.

If you’re a fan of Personal Software Process (PSP) or Team Software Process (TSP), you’ll appreciate the fact that checklists are one of the best ways to quickly, efficiency, and effectively radically improve quality, for yourself or for the team.  Of course, that depends on the quality of the checklist, and your focus on actually applying it, and treating it like a living document, and keeping it updated with your latest insights and actions.

If you adopt checklists as your tool of choice for continuous improvement, you’ll be in good company.  It’s how McDonald’s and Disney spread best practices.  It’s how the best hospitals reduce errors and raise the quality bar.   And, it’s even how the Air Force keeps fighter pilots from falling prey to task saturation.

Like anything, the value of the checklists depends on the user and the usage, and if you treat it as a static thing, that’s when problems happen.   Use it as a baseline and adapt it to your needs, and update it based on your latest learnings.

If you do that, and you treat your checklists as continuous learning tools, and you continue to evolve and adapt them, then your checklists will serve you well.

Ugh … it looks like this post ran into some scope creep.  This was supposed to be just letting you know that I have a new version available of my focus checklist.

Luckily, my 5-minute timebox in this case, reeled me back in.

Enjoy.

PS – It’s worth noting that the practices behind this focus checklist are industrial strength.   Folks with ADD and ADHD have used the practices in this checklist to retrain their brain to focus with skill.  They learned to direct and redirect their attention, and to enjoy the process of focusing their mind on meaningful results.

Sehr geehrte Damen und Herren! Wir begrüßen Sie auf dem Flug von Graz nach Düsseldorf. Bitte schnallen Sie sich an, stellen Sie Ihre Sitzlehne aufrecht und klappen Sie Ihre…

Da saß ich nun im Flugzeug und hörte mit einem Ohr die Durchsage der Flugbeleiterin. Neben mir ein Herr, Mitte 60, graumelierte Haare, perfekt sitzender Anzug. Seine Augen auf mein Buch gerichtet. Auf das kleine Agile-Buch von Sander Hoogendoorn. Da wurde es mir ein wenig bunt und ich erwiderte seinen Blick. Plötzlich sagte mein Sitznachbar zu mir: „Entschuldigen Sie, aber ich „missbrauche“ Sie, um in Ihrem interessanten Buch zu lesen. Was bedeutet agile oder besser gesagt, wie können Projekte agil werden?“

So starteten wir agil in Richtung Düsseldorf … und in ein Gespräch über Scrum und Wasserfall, über Iterationen und Releases, über Change Management und Komfortzonen. „Alles schön und gut in der Theorie“, meinte er. „Wären da nicht die Menschen mit all ihren Befindlichkeiten.“ Da horchte ich plötzlich auf und es machte „klick“ in meinem Kopf. Natürlich! Recht hat er! So recht!

Denn: was ist Scrum? Ein Steuerungsinstrument? Ein Change-Management-Ansatz? Eine Einstellung? Die innere Haltung? Agil?

Ja, alles.

Wenn das alles auf Scrum zutrifft, was tut diese geballte Ladung an Veränderung dann mit uns?
Können wir davon ausgehen, dass unsere Teams, ScrumMaster, Product Owner, Manager oder sonstige Stakeholder einfach schwupsdiwups anfangen agil zu denken, Veränderungen ohne Hindernisse  akzeptieren und zur agilen Tagesordnung übergehen?

Nein! Meine ich.

Seit geraumer Zeit wird zu Projektbeginn das bestmögliche Team von Entwicklern, Fachexperten und Testern zusammengestellt. Nach Abschluss des Projektes werden die Teammitglieder wieder getrennt und in neuen Projekten (oft mit neuen Teammitgliedern) eingesetzt. Das Prinzip geht von den besten verfügbaren Einzelpersonen aus, aber nicht von den besten verfügbaren Teams. In vielen Projekten dauert es leider sehr lange, bis diese Einzelpersonen zu einem effizienten und produktiven Team werden. Da muss ich Sander Hoogendoorn Recht geben. Aber warum ist das so?

Weil es in Projekten eben menschelt. Erst recht, wenn wir von Wasserfall auf agil wechseln. Weil Veränderungsprozesse Menschen in Ausnahmezustand versetzen. Weil die Veränderung einer Einstellung oder die Weiterentwicklung der inneren Haltung Zeit brauchen. Zeit, um Ängste zu überwinden und Zeit, um den Nutzen zu erkennen. Vor allem den Nutzen für sich selbst.

Sozialpsychologisch betrachtet sind Menschen „bilanzierende Wesen, die Veränderung als kognitive und emotionale Unsicherheiten erleben. Emotionen wirken dabei wie Vergrößerungsgläser. Change Prozesse sind hochemotional und verursachen somit emotionale Spannungszustände. Und was machen die emotionalen Spannungszustände mit uns? Sie hindern uns daran, den gesunden Menschenverstand einzuschalten, effizient zu arbeiten, gewaltfrei und lösungsorientiert zu kommunizieren, Konflikte zu vermeiden oder schicke Codes zu schreiben.

Wenn wir also davon ausgehen, dass Change Prozesse emotionale Spannungszustände in uns verursachen, können wir dann gleich zu Beginn des Projektes von erfolgreichen Sprints ausgehen bzw. dürfen wir uns dann wundern, wenn diese eben nicht erfolgreich werden? Was wäre dann die logische Konsequenz daraus? Denken wir mal bewusst darüber nach…

So diskutierte ich mit meinem interessanten Sitznachbarn, als wir die Durchsage unserer Flugbegleiterin mit einem Ohr wahrnahmen: “Wir befinden uns im Landeanflug auf Düsseldorf. Legen Sie bitte Ihre Sicherheitsgurte an, stellen Sie Ihre Sitzlehnen aufrecht und schalten Sie Ihre elektronischen Geräte aus.”

Und mein agiles Landing war perfekt!

Related posts:

1. Volles Scrum ist gefragt!
2. Agile Estimation | Grundlagen
3. Wenn es keine Fragen mehr gibt …

Lean Startup is a disciplined, scientific and capital efficient method for discovering and building products and services that people love. Pioneered by entrepreneur and engineer, Eric Ries, the Lean Startup method will thoroughly change how you think about and practice agility. Born from the struggles and ultimate triumphs of successful software companies, Lean Startups use [...]

Michael posted last week about A Developer Dashboard for All Your Tools.   He showed how you can use custom tabs to display external Web pages in your Assembla space.  This is a cheap trick with powerful effects on focusing attention. In this article we will explain how to set up a custom tab.

Setup

Go to your Admin tab and select "Tools".  You will find the following panel:

Click on the button to add a new tab to the top of your space.  Select the new tab.  You will see a form where you can configure it.

Now, sort your tab into the position that you want.  You can go back to the Admin tab and select Appearance.  You will see a Navigation panel where you can drag your tabs into the order you want.

Examples

I get a management report with key financial numbers on a Google spreadsheet. After moving it to a custom tab, I look at it more frequently.

As you can see below, we put Jenkins in a custom tab, and we used our Jenkins oAuth plugin to log viewers into Jenkins with their Assembla accounts.

We keep a lot of monitoring tools in our tab bar:

Scrum: it’s not just for development teams anymore. LeadingAgile’s resident sales guru, Eric Kristfelt, shares his experience on implementing Agile on a sales team.

After working as a sales manager at two different Agile organizations I am often asked if sales can be Agile, and if so, how is it implemented?

At my previous company, several departments chose to align with the development team’s 2-week sprints/builds.  The marketing department started using a Kanban/Scrum approach, and it made sense as the marketing goals naturally aligned with the builds and releases.  But would a Kanban/Scrum approach make sense for the Sales team? And if it makes sense, where should we start?

Step 1: Training: It is important for the teams to be trained on Agile/Scrum so that they understand the methodology and the goals.  It can help everyone if the sales team begins to gain a better understanding of the development cycle.  One challenge we faced was determining how to set-up our teams. Typically, sales professionals are viewed as individual contributors and not part of a team.  We found that management had more challenges moving to a team approach than the sales professionals.  Successful sales people are accustomed to working within a team given today’s complex sales models — which mean working with everyone from sales engineers to consultants to management and even Legal teams.  Most individual contributors realize that this is the reality of today’s business.

Step 2: Stand up:  Stand ups allow teams to adapt and react quickly to how the process is working for customers and external teams.  Stand ups are a natural for sales teams; most sales people are impatient and like short meetings that are to the point, and that can help them resolve problems and focus on accomplishments.  At my former company, if a particular impediment was outside the scope of the sales team, we might invite members from other teams to attend the next stand up. Our sales people hated being required to listen to others dig into their own issues, so moving longer discussions to “post meeting” status was popular among our sales people.

Step 3: Sprints and Retrospectives: For sales, the sprint cycle may be much longer than recommended for a typical development team, but it’s important for sales managers to follow the sprint structure. Sales teams often work on monthly goals, so that’s how we set up our sprints–much longer than a development sprint– but a period of time that made sense for our goals. We could determine what we accomplished the previous month, review impediments that were not resolved, and determine our goals for the upcoming month/

quarter.  These types of reviews are very natural for sales teams; although a step that many skip in the busy day-to-day pursuit of closing deals.

Step 4: Re-interpreting Product Backlog:  Our team implemented an EPIC board (Customers) and Tasks were set up as “backlog items” with a “pending”, “in-progress”, or “completed” status. Suddenly, the entire sales and sales management team had a clear visual for the enormity of tasks during the iteration.  Velocity (or, in this case, expected sales per iteration) was available for inspection and adaption.  This approach allowed the sales team to focus on their workload, and it helped minimize distractions from management. Even the engineering teams would walk by the boards and understand what was going on with accounts and opportunities.

Challenges to Agile Sales Models:

Switching to Agile wasn’t easy on the management team. How would they hold individual sales people responsible?  How would they compensate each sales rep?  What if someone on the team wasn’t making enough calls? Many executives thought the stand up meetings would be too short to accomplish all of their weekly goals.

The company I worked for set up a true sales scrum team with monthly iterations.  The teams hit the goals set up by management, and for 6 months we iterated and worked as a Scrum Sales Team. From a sales attainment perspective, it was the most successful the team had ever been.

For reasons I still fail to understand, the company restructured itself, and the Scrum Sales Teams were eliminated, but not before we realized the power of Agile within sales.  It was the first time that entire teams reached quotas assigned to the company, as opposed to just individual sales contributors.  Onboarding and ramping up new reps happened more quickly; most likely due to interfacing with successful senior reps.

Lessons Learned:

By following the steps in Scrum, management learned that sales can lend itself easily to an Agile environment.  Individuals found that this shared work model led to more consistent revenue and compensation in addition to a more even workload.  No longer did the “sales stars” work much harder than everyone else.  Each team member focused on his/her own domain expertise.

While we found it difficult to find “Renaissance sales people”, we were able to create the perfect sales person by matching skills, or by filling voids by marrying strengths and weaknesses of individuals within every given team.

Scrum also allowed a better quality of life:  Sales teams had time to enjoy vacation or family time because the team could step in to support customers while any single member was away.  Our teams were self-managing, and the sales manager acted like a Product Owner as opposed to a Scrum Master.

Let me know your thoughts and experiences implementing an Agile sales model.

–Eric Kristfelt

The post Agile and Sales: Reflections on My First Scrum Sales Team appeared first on LeadingAgile.

At XP2013, Christian Trabold and I will be giving a tutorial on Implementing Continuous Delivery. In order to prepare for the workshop we ask you to bring a computer and do the following before the workshop:

1. Install VirtualBox (https://www.virtualbox.org/wiki/Downloads)
2. Install Vagrant with minimum of v1.2.1 (http://downloads.vagrantup.com/tags/v1.2.1)
3. Ensure that you have at least 2.5GB of free space on your hard disk
4. Ensure that your USB port is working so that we can provide the image via a portable Hard Drive/Stick.
5. Make sure you don’t use local ports like 8080 and 8153 (We need these ports for accessing the apps on the VirtualMachine)

High-performing team don’t just happen. While the structures of agile frameworks and the principles of the Agile Manifesto help (a lot), the human-interaction component of a team and organization is wide and deep. People often ask me how they can tell if a team is progressing toward a high-performing state (if they are jelling well) and how to determine the sort of help needed to move teams forward. Tuckman’s model of team development offers one way to explore these questions with agile teams.

Tuckman Model of Team Development

Many models of human interaction have been proposed by sociologists. Each have adherents and detractors, strengths and weaknesses. I like to learn and use these models not as hard rules but as paths to think about improvement or change. Remember:

Essentially, all models are wrong, but some are useful. – George E. P. Box

Bruce Tuckman introduced his theory called “Tuckman’s Stages” in 1965. It is actually fairly well known in the business world though many do not know the source. Most know it by the names of the four phases of development that Tuckman originally proposed: Forming – Storming – Norming – Performing. The goal, of course, is to become Performing, working well together in a fluid way.

The descriptions of each phase help us get a feel for the team dynamic at any point and time. Let me elaborate what these phases might look like in a working agile team. Think of these as things you might see and hear from teams in each phase.

Forming

• Everyone is polite to each other.
• Each person concentrates on their “own” tasks.
• Comments for improvement are phrased in safe “we” and “maybe” language.
• “I do my part. I hope you do yours.”
• “We have no differences.”

Storming

• People form small, amorphous sub-cliques in the hall or at lunch to talk about a team member who is not present.
• People point out who is letting the team down, typically not directly to that person at first.
• Comments become direct and disagreements grow stronger.
• “I’m doing my part. Why aren’t you doing yours?”
• “I hate your differences.”

Norming

• Team members request specific things of each other.
• People cooperate and coordinate explicitly as needed.
• Comments are about getting help to get stuff done.
• “We are doing the work. Thanks for the help.”
• “We work through our differences.”

Performing

• Team members know each other’s weaknesses and fill in the gaps for each other without discussion.
• People call each other out and willingly give account for their successes and failings.
• Comments are about the work and getting it done.
• “We are awesome. Let’s do more stuff!”
• “Our differences make us stronger.”

Continuous Improvement with Tuckman

In my experience most teams get stuck in a Forming-Storming cycle. There are many possible reasons for this, such as:

• Members are swapped in and out, causing resets back to Forming.
• Management keeps suppressing getting through the storming phase. They decide, personally or by company culture, that “conflict is bad” so they step in too soon, smoothing things over so they never resolve.
• The team members themselves are uncomfortable with conflict and the combination of strength and vulnerability productive conflict requires.

Performing teams are rare because getting through Storming is hard! Also please keep in mind that these stages are not necessarily a linear progression. Even a Performing team will cycle to Storming or Forming in different circumstances and at different times. The goal is to use this structure as a way to reflect on what may need to change for improvements to be realized, to get back and stay in Performing most of the time.

As a practitioner seeking improvement, look for behaviors that indicate a throttling of deep communication. Whether you accept the “Tuckman Stages” as relevant or not, they can be useful to help find places where more trust is needed.

What resources have you seen that are helpful to getting teams to Performing, where the work really works?

The post Continuous Improvement: Thoughts On Tuckman and Teams appeared first on BigVisible Solutions.

Modern Agile software development approaches like Scrum recommend a “just in time” vision of application development that tends to make people focus only on the activities that are directly useful for the current sprint. How can you include an activity with a long-term perspective like enterprise software architecture in the iterative process of Scrum? Author: Markus van Aardt, Adamantium Software Engineering, http://www.adamantiumse.com/ Agile approaches have brought a renewal in software development and delivery practices over the last decade. Yet, iterative and incremental development methods have been around since the 1980’s and are ...

Timeboxing is the practice of ending a meeting exactly on time regardless of the state of discussion or the desire of participants.  In Scrum, the combined length of the Sprint Review and Retrospective Meetings is determined by the length of the Sprint.  For example, a one week long Sprint has Sprint Review and Retrospective Meetings that are timeboxed to two hours in total.  It is acceptable for the meetings to take less time, but not more.  A two week long Sprint has a Sprint Planning Meeting that is timeboxed to four hours.  Keeping the Sprint Review and Retrospective Meetings timeboxed has two beneficial effects: one, the team keeps the overhead dedicated to meetings to a relatively low level, and two, the team learns to do effective inspect and adapt in a very short period of time.  If the meetings are not timeboxed, then typically the team will keep going until they are “done”… and break the timebox of the overall Sprint.

Sorry to be pushing back the 100 in 100 project but hopefully the readers of that will find this blog just as interesting.  If you are not familiar with Kanban, you should get familiar with it. It is one of the most exciting things to have happened in the Agile space.  See my article De-Mystifying Kanban for a brief introduction. I have been involved in an interesting discussion on the Kanban...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

I’m looking forward to going to the Software Practice Advancement conference in London again. Not just because of the usual high density of hands-on sessions. The diversity of presenter backgrounds and session topics should make for an interesting mix. I see research academics business owners (not just consultants, but running product businesses as well), developers and even aspiring comedians (thinking of Emanuel Gaillot and Jonathan Perret with their pair programming parody).
Topics are ranging from ethics, Artificial Intelligence, property based tdd and hard-won experience using specific tools and plaforms (nodejs, cloud).

To add to the mix, I’ll be co-hosting a session on a research topic: Answer Set Programming and the next iteration of The joy of TDD on the Raspberry Pi.

Have a look at the programme or even better, register

Jeder von uns kennt die lähmende Kraft von Angstgefühlen. Angst zu haben bedeutet, der Situation nicht gewachsen zu sein. Unser aufrechter Gang, unser Stolz, unsere ganze persönliche Souveränität verblassen im Angesicht der Angst. Und trotzdem – oder gerade deshalb – ist Angst eine unserer wichtigsten Antriebskräfte. Ängste fordern uns dazu auf, sie zu überwinden. Und manchmal werden wir uns der Angst erst bewusst, nachdem wir sie eigentlich schon überwunden hatten: Das Kind, das die Hand seiner Eltern beim Laufen festhält, steht plötzlich selbständig im Raum. Erst wenn es merkt, dass keine erwachsenen Hände es mehr halten, taumelt es und fordert die stützende Hand zurück. Der Passagier mit Höhenangst lässt den Blick nichtsahnend aus dem Fenster schweifen – und merkt dann zu seinem Entsetzen, dass die Häuser 10 Kilometer unter seinen Füßen vorbeirauschen.

In seinem mittlerweile fünfzig Jahre alten Buch postuliert Fritz Riemann vier so genannte Grundformen der Angst:

1. Die Angst vor der Hingabe
2. Die Angst vor der Selbstwerdung
3. Die Angst vor der Veränderung
4. Die Angst vor der Notwendigkeit

Mit einer Fülle an Beispielen aus seiner therapeutischen Erfahrung beschreibt Riemann Verhaltensmuster, die er jeweils mit diesen vier Ängsten in Verbindung bringt. Als Leser ist man schnell versucht, die eigene Persönlichkeit und die der Mitmenschen auf zutreffende Verhaltensmuster zu prüfen.

Spannende Erkenntnis: In ihrer Extremform verkrüppeln uns die Grundformen der Angst und machen uns zu Menschen, die keine Beziehung zu ihrer Umwelt aufbauen können. Zugleich aber liegen jeder dieser Ängste Sehnsüchte zu Grunde (Riemann nennt sie nüchtern “Forderungen”), die unser Menschsein ausmachen. Diese Sehnsüchte korrespondieren also mit den Ängsten, stehen zum Teil in Spannung zueinander, und sind bei jedem Menschen unterschiedlich stark ausgesprägt:

1. Dass wir ein einmaliges Individuum werden sollen.
2. Dass wir uns der Welt, dem Leben und den Mitmenschen vertrauend öffnen.
3. Dass wir die Dauer anstreben sollen.
4. Dass wir immer bereit sein sollen, uns zu wandeln.

Wer also Angst vor (4) dem ewig Gleichen, vor Routine, vor Sesshaftigkeit und Wiederholung hat, der hat zugleich auch die Kraft, neue Dinge anzupacken und Altes komplett über den Haufen zu werfen. Jemand, bei dem die Angst vor (3) der Veränderung heraussticht, kann nicht nur ein tiefes und gründliches Verständnis von Sachverhalten entwickeln, sondern bringt auch hohe Zuverlässigkeit und Ausdauer mit sich. Der Mensch, der (1) Hingabe fürchtet, kann souverän und unabhängig auftreten, Herausforderungen mutig angehen und Dinge sachlich-kühl betrachten. Dagegen ist derjenige, den die Angst vor (2) der Selbstwerdung umtreibt, in der Lage, sich durch seine Hingabe in andere Menschen hineinzuversetzen und eine empathische Nähe aufzubauen, die ein starkes, inniges Vertrauensverhältnis ermöglicht.

Bei aller Gefahr, Menschen durch solche Kategorien in Schubladen zu stecken, können die Riemannschen Grundängste als Orientierung durchaus hilfreich sein. Helfen sie uns doch, Menschen in ihrer Vielfalt zu begreifen und zu verstehen, dass erst diese Vielfalt unser Miteinander sinnvoll macht. Da wo ich dreimal zögere, kann meine Kollegin einfach entscheiden. Und bevor sie anderen nochmal auf die Füße tritt, kann ich sie zu einem Perspektivenwechsel ermuntern.

Ich denke, dass diese Verhaltensmuster sich – freilich mit Abstrichen – auch auf Unternehmen anwenden lassen. So wird ein Start-Up vermutlich eine andere Einstellung zu Dauer und Veränderung haben als ein Konzern mit einem hohen Grad an formalisierten Normen. Und ein Unternehmen, das jahrzehntelang einsam auf dem Markt herrschen konnte, wird anders mit der Umwelt interagieren als ein solches, das seit eh und je zur Kooperation mit der Konkurrenz gezwungen war.

Eine spannende Übung zum Schluss: Schau dir deinen engeren Kollegenkreis (z.B. dein Scrum-Team) an und finde heraus, wie stark die vier Sehnsüchte darin ausgeprägt sind. Gibt es vielleicht ein übergreifendes Muster, das die ganze Gruppe beherrscht? Das ist in alteingesessenen Teams mit einer starken Führungsperson häufig der Fall. Vielleicht ist deine Gruppe aber auch reich an Vielfalt, spannend und angespannt zugleich?

Überlege dir dann, wann dir deine Gruppe zum letzten Mal Schwierigkeiten bereitet hat. Was ist dort passiert, wer hat wie gehandelt? Beschränke dich auf die beobachtbaren Tatsachen und darauf, wie du dich dabei gefühlt hast. Mache weiter, indem du eine Situation in Erinnerung rufst, in der du deiner Gruppe Schwierigkeiten bereitet hast. Beschränke dich wieder auf die beobachtbaren Tatsachen und darauf, wie du dich dabei gefühlt hast.

Schau dir dann die vier Sehnsüchte nochmal an und versuche, deine Gruppe als empfindliches Gleichgewichtsorgan zu sehen, bei dem jede Veränderung, jeder Anstoß das System ins Wanken bringen kann. Hast du jetzt ein besseres Gefühl dafür, wie deine Gruppe mitsamt ihrer einzelnen Mitglieder tickt – und was sie auszeichnet? Im Anschluss daran kannst du eine nach innen gerichtete Retrospektive mit deiner Gruppe durchführen. Hierzu eignet sich zum Beispiel die Naikan-Übung, von unserem Coach Dieter Rösner hier beschrieben (http://borisgloger.com/2012/09/23/ich-du-wir-von-austausch-feedback-und-weiterentwicklung-in-teams/).

Literatur
Riemann, Fritz (2011): Grundformen der Angst. Ernst Reinhardt Verlag. München und Basel. Vierzigste Auflage.

Related posts:

1. Raus aus der binären Welt!
2. Schuldzuweisungen verhindern Lernen
3. Mut – just do it!

There’s been some interest in the new SAFE ScrumXP graphic (the “Little Picture”) we rolled out a couple of weeks back as part of the rework of some of the Team Level articles (see post), so we’ve just posted it for Download on the Big Picture download tab.

 

 

Team commitment is a wonderful and sometimes fragile thing. Many responses to my description of it are indications of how frequently the word “commitment” is used in a dysfunctional manner. Indeed, the post was prompted by similar conversations.

Believe me, I’ve seen these dysfunctions many times. They are so numerous and varied that no catalog of them could be complete. It’s not the word, commitment, that causes the problems, however. And avoiding that word will not solve the problems. Instead, we have to look at the behavior and attitudes behind the problems in order to reliably recognize them and choose strategies for correcting them.

A common fundamental issue is distrust between managers and workers. If these two groups see themselves in opposition, rather than in alignment, then even the most well-intentioned statement may be taken poorly. This can engender a response that furthers the distrust. The reinforcing feedback cycle that results can drive a deep wedge between the two, and create persistent stereotypes.

When a healthy team looks at each other and asks themselves for mutual commitment, they’re committing to working together in trying to achieve a common goal. When someone off the team asks for a commitment, it no longer feels mutual. It feels like being asked to make a promise. Often it feels like you’re being set up to take the blame for something outside your control. Far too many times, these feelings are correct—you are being asked to promise something you can’t reasonably promise so that you can be blamed when things don’t go as desired. And the person doing so may, in fact, be in the same bind, and looking for a scapegoat to take the heat off themselves.

When fearful of being blamed if a promise is not met, for whatever reason, it’s a natural tendency to avoid making the promise at all. When feeling pressured to make a promise, it seems safest to promise as little as possible. Such evasion tactics do not typically go unnoticed. Rather than being seen as an attempt to avoid unfair blame, they are likely to be interpreted as an attempt to avoid work or responsibility.

This avoidance, or general disappointment in the rate of accomplishments, may lead to a request to “commit to a little more.” This is a clear sign that we’re dealing with a negotiation of a promise rather than a voluntary commitment. Even a request for “stretch goals” sends the same message. The message is that you could do more, but you’re choosing to not.

And so the cycle proceeds.

There are many similar ways that such dysfunctions can grow. There are probably very few in the Information Technology field who have not experienced some of these dysfunctions. Some leave and find happier places to work. Some work to make their place happier. And some think this is just the way things are.

It’s not easy unwinding such a spiral. It’s not the word, commitment, that causes the problems. And avoiding that word will not solve the problems. It takes communication, growing transparency, and growing trust. It’s difficult and dangerous to attempt these in a low-trust blaming environment. Courage is required to attempt it. Skill and/or luck is required to succeed.

I’m working my way through my massive book backlog, and doing reviews as a I go along.   Yesterday, I wrote my review of Mastermind: How To Think Like Sherlock Holmes.

Today, I read and wrote my review of The Innovative Team:  Unleashing Creative Potential for Breakthrough Results.

It’s perfect timing.  Just yesterday a friend ask me if there’s some science and proven practices that we could apply to create high-performance teams, especially when there is a lot of innovation involved and we need to be more agile in how we execute our projects.

At the same time, we need to give enough time to really explore the problem domain and build some solid foundation to base our solutions on.

The Innovative Team directly addresses this dilemma.  And it does so in a pragmatic way.

It does do by framing out the 4 stages of innovation and the corresponding cognitive style preferences that people tend to have.  The book then shows you how to leverage these different cognitive styles that can often create conflict during the project cycle.  It includes specific proven practices for elaborating on ideas and then converging on solutions and keeping things moving forward.  At the same time, the framework is all about getting the best out of every one on the team and bringing them along.

It’s a recipe for creating and leading high-performance teams that deliver high-impact, innovative solutions for big challenges.

Here is a quick look at some of the things I found especially interesting …

The Four Stages of Innovation:

1. Clarify the situation
2. Generate Ideas
3. Develop Solutions
4. Implement Plans

The 4 ForeSight Cognitive Styles

Here is a brief summary of each:

1. Clarifiers – Analyze and clarify the situation
2. Ideators – Blue sky or big picture thinkers, continuously generate big ideas
3. Developers – Tirelessly focus on developing and perfecting the solution.
4. Implementers – Implementing the plan and moving to the next project.

Common Patterns of the 4 Cognitive Styles in Action (+ The Integrator Style)

Here are some common scenarios that you might see, or see yourself in, when working on projects and going through the various stages of innovation:

1. “For example, if you really like to generate ideas and also feel adept at clarifying the challenges, you are probably full of energy out of the starting gate, identifying and solving issues with ease, coming up with targeted ideas that you feel perfectly (and instantly) solve the problem at hand.  But because you do not devote much energy to later stages in the process, you might find that these solutions ultimately fall short of their mark because they are not properly developed or implemented.”
2. “What if you really like developing an idea and putting it into action but had no energy for clarifying  the challenge or generating a bunch  of potential options for it?  This would mean that you enjoy the final steps of the process – seeing well-thought-out ideas come to fruition, and watching people welcome and readily adapt to the new solutions thanks to how thoroughly they were developed to fit the situation.  When your ideas have failed, it’s often not the fault of how well they were developed but because they were not well targeted.  They may have solved a problem or met a need, just not the right one.”
3. “Some people may have nearly equal preference for three of the four stages.  For example, they may like clarifying, ideating, and developing but not implementation.  These people would be comfortable analyzing, coming up with ideas, and tinkering with them toward perfection, but they often can overestimate how much they can get done and you may see them step back when it’s time to put the ideas into action.”
4. “There are of course many other combinations of types, each with their potential plusses and negatives.  In our story, the character Maya represents of the more common combinations of preferences – the integrator.  She was comfortable with all the stages in the process with no clear preference for one stage or another.  Integrators are indeed a special group.  If you are leading a team and are lucky enough to have an integrator in the mix, you may be able to leverage that person’s abilities strategically to move the team on to the next phase of the process or to act as a mediator between team members of different preferences.”

As you can imagine, this is a powerful books, especially if you do project work.  It’s also powerful even if you just want to improve your own ability to innovate, either as a one-man band, or as part of a larger team, or leading a high-performance team.

If you want a deep dive on the book and more highlights to get a better sense of what this book is all about, check out my review:

The Innovative Team:  Unleashing Creative Potential for Breakthrough Results.

You Might Also Like

High-Leverage Strategies for Innovation

Lessons Learned from the Most Successful Innovators

Mastermind: How To Think Like Sherlock Holmes

Nobody Wants to Invest

Innovation Quotes

This was originally titled "How I Can Endorse SAFe & the Kanban Method" due to consternation my endorsing SAFe seems to be causing some in the Kanban community.  But then I realized that most folks in the Agile community don't have this concern, so I thought it's current title to be more appropriate.  In a nutshell, I endorse both, because they both have value. I was recently asked how I can...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Agile Coach Camp Canada, now in its 4th year, is a highly collaborative, self-organized annual event for everyone involved in coaching, training, mentoring and leading Agile organizations, teams and individuals. This is a great event to help you take your skills to the next level learning from your peers.

Want to win a free ticket? I have two to give away.

Anyone who signs up for our mailing list by June 6th will be eligible for the draw.

Subscribe to our mailing list

I will do the “draw” using my a random number generator and a copy of excel :-). Once we’ve completed the draw we will email the winners and post a short announcement on this blog.

User Story is a most widely used tool in many Agile methods. Sooner or later you will need to work on some of them or you will need to write a few yourself. At first glance the whole idea may look strange. All those agilists tell you about index cards, about putting them on the wall. They organize them into themes, create some strange maps, call some of them epics, etc.

Let’s start from the beginning. User story describes part of your requirements or part of whatever you are trying to achieve in general. In software development we got used to some template (but this is just an example):

“As a [user/role] I want a system to have [some functionality] so that I can achieve [some goal].”

For example:

“As a blog author (my role) I want to be able to create categories for my posts (functionality), so that I can organize all the posts that I write into related topics for better reading (the goal / why I need this).”

But also:

“As a doctor (role) I need to have access to a patients health records and history before the patient comes to a hospital for a scheduled visit (process improvement) so that I can prepare a plan and book some procedures and a patient stay shorter (the goal / why I need this)”

The goal

Actually a template is not so important and if you like different one, then just use it. The most important is a goal part. A user story should bring some value, otherwise why would you want to do it? When writing a story always think about presenting it to a person mentioned in a story (doing a demo)? How would you show that the goal was achieved? If answering this question is a problem, then you should probably rethink your story.

Big and small stories

We usually tell that a story should fit into an index card or a post-it note. The point is not to put too much detail in a single story, but it’s not a level of detail that matters. It’s about story complexity and the expected amount of work required to be done. You should be able to complete a story in some reasonable time. If you work iteratively, then your story should fit into iteration. If you measure cycle time, then the best amount of work put in a single story would fit more or less in that time frame.

Does it mean a story cannot be bigger. No, not at all. Sometimes you will have just a raw idea about what needs to be done. Your story may initially be just called “Customer service improvement”. We will call it an epic. This story will get more details over time. You will split it into smaller stories that can actually be implemented.

Lifecycle

A story have its own lifecycle. It lands in your backlog as an epic, then it gets some details and becomes a set of stories that we can call ready. This is time to start implementing them. They will now go from to do to completed through some various states (depending on your process). There is one more important step…

A story needs to be accepted. This is when you present the outcomes of your work. You will verify if that story meets the set goal. If not, then it will require some more work (which means it will get rejected), otherwise it’s done.

Themes and story mapping

If you are dealing with a complex product or service then you may have a lot of stories to deal with. Having a large backlog is in my opinion a bad idea in general (and I will write a bout it in a few days) but if you do have such a backlog then it’s a good idea to group stories in themes. Themes will usually evolve from groups of epics.

There is also a very useful practice called story mapping. It’s out of scope of this post and I encourage you to read more about it at Jeff Patton’s blog.

What to do next?

So let’s get back to the main question. Why should you care about stories?

My answer is because they are a powerful tool. I would encourage you to think about user stories even if you do not intend to dive into Agile world. They will give you a good perspective and will help you focus on the right things. If you want to learn more about effectively using stories there is a book I especially like. It’s “User Stories Applied” by Mike Cohn.

It is Memorial Day weekend and time for another edition of Joe’s Unofficial Scrum Checklist.

No, not really.

But someone in class asked what he could use to check that his team’s were using Scrum well.  I suggested:

1. The ScrumButt Test – 8 points.
2. “A list summarizing Scrum” (V.5)  – 2 sides of one page.  Fairly packed.
3. Joe’s Unofficial Scrum Checklist (Now V1.3)

Well, I did not at that time recommend #3.  But I do now.

I guess it bears repeating: We only seek to do Scrum better because we believe in almost all cases that better Scrum leads to better results. For you, for your Team, for your customers.