I was helping a mentee take a new view on their business, so they could transform their business to compete in a new arena.   Here are the 7 ways I outlined for them to get a better view on their business to shape significant change:

1. What are the key deliverables that the company cares about? (Who are the stakeholders and why do they care?)
2. How does the money flow? (Who funds and why?   If they gave you more money, what more would you do? If you got less money, what would be cut?   This gives you a fast business sense)
3. What is the cadence of your deliverables?  (Do you ship 3 big thingies or 30 thingies per year? .. what would a “fast” cadence look like?   More importantly, what would people value?  For example, can you focus on 3 big wins each quarter that have high impact?)
4. What’s the roadmap look like?  (Can you put it on a one-slider to show the big impact in a way others get?)
5. What are the critical few KPIs that tell you whether you are keeping up, falling behind, or changing the game?
6. What is your unique set of capabilities of your product/service?
7. What is the unique set of capabilities of your people?

If you can answer those without a lot of work – congrats!

The above lens gives you quick insight and a critical view into the customer, the value you provide, the cost, and the capabilities you can use to drive meaningful change and transformation.

To put that into context and apply it, when business leaders look to shape a business, they tend to look at the capabilities.  They want to know what’s unique and what’s redundant.   If you can’t differentiate at your capabilities, then you have a problem articulating your unique value.

Capabilities help give you a simple language for talking about value and unique strengths.  They are also a business tool for consolidating and improving efficiencies by maturing or outsourcing capabilities.

Use them wisely.

A simple (and misunderstood) way people think of their change initiative like this:

Their organization is just sitting there, ready to change in wonderful ways. We just have to tell people how great our new initiative is and they will be lining up to learn more and make things happen. Right?

Unfortunately, organizations are complex adaptive systems with their own dynamics and forces at play.

Note: we could be talking about the whole organization, a group, or a team here.

Forces Acting on an Organization

In the following diagram, I will use the word Culture to capture the existing forces at play in an organization. The real situation will be of course much more complex with various attractors influencing the system in different ways, but this will reveal the essence of what I have seen with change initiatives around Agile.

 

Some remarks on the diagram:

1. It is difficult for a change initiative to make real progress if it runs against the culture of the organizations (as is usually the case with Agile). It’s like trying to roll a giant boulder up hill.
2. When forces pull an object in different directions, the object is under tension. Too much tension and the organization will be damaged (red squiggles). So, when you notice resistance, applying more force will damage your organization. A few weeks ago, this simple explanation helped a client reduce tension by shifting the blue rather than adding more green.
3. The change initiative will eventually fail. Why? Energy is required to keep the change initiative going. Eventually, people will just declare victory or give up and move on to the next initiative. At this point the boulder rolls down the hill, crushing supporters of the initiative on the way.

Rolling Rocks Downhill

A much better way to go about this is to forget about change strategies and work on an organization’s culture so that it moves the organization towards the desired outcome without conflict. This is of course a vastly simplified version of reality, but it helps us stop and consider the root cause of dynamics and forces in an organization.

Acknowledgments

There is a great exercise on force-field analysis called “May the Forces Be With You” that I learned from The big book of humorous training games.

Olivier Lafontan wrote the insightful post Being an Agile transition coach feels like Sisyphus that inspired the boulder in my narrative.

The phrase “Rolling Rocks Downhill” came to mind from Clarke Ching’s new book by that title.

Related posts:

1. Tactics, Strategy, & Culture – A Model for Thinking about Organizational Change The following diagram is a powerful mental frame to help...
2. How to Build a Culture Bubble The post is about how one can create a bubble...
3. Build Culture Adapters to Avoid Agile Failure The purpose of this post is to explain why building...

Related posts brought to you by Yet Another Related Posts Plugin.

Newly formed organizations have the benefit of hiring teams, forming culture, and building structure from scratch. Mature organizations do not have this advantage and to stay competitive with newer startups will rely on change initiatives for a rebirth to bring back the spark they once had.

Many of these companies are attempting to become agile, nimbler, leaner or more customer-responsive with varying degrees of success. The struggle, I believe, for these organizations to truly change occurs when leaders are not ready for what becoming Agile will bring – the amplification of both the good and bad behaviors from their current situation.

If you have hired well, the amplification will result in a near immediate boost in a sense of empowerment and productivity for your people. Bright, hard working people thrive on Agile teams. The reaction to this amplification must be a letting go of control by leaders and of overwhelming encouragement from your leaders.

If your organization has not hired well, the amplification will put a spotlight on those who have not been performing or are not good teammates. The reaction must be a hard look at current hiring practices and your approach to performance management (if you can really “manage” performance at all). Fresh thinking from leaders will be needed in this space.

If your technology has been allowed to grow in complexity and fragility, the amplification will be in frustration. Agile teams will begin to increase the throughput of production-ready code but will not be able to realize customer value quickly enough. The reaction must be simplification and a shift to being “anti-fragile.”

If there is a history of having a fractured or siloed organization, the divide between groups will be more apparent than ever. The reaction from leadership must be to foster and facilitate reconciliation and connection. Don’t expect people “to go figure it out.” Rather, become a model for the behaviour your people need. Bring people together. Solve things together.

If there is a lack of vision, direction, or prioritization, the amplification will reveal a craving for it. The reaction must be to discover what the organization should be passionate about and provide the motivation to achieve it. Agile teams respond amazingly well to a well-crafted and well-communicated vision.

Leaders, be ready for and react to what will be amplified during your transformation to Agile. Meaningful, lasting change and more importantly, your people, will depend on it.

 

The post Agile, The Amplifier appeared first on Illustrated Agile.

Alex has been in town for the last few weeks, and we have been working hard on SAFe and the associated courseware. We started a week or so back by reviewing the product backlog item we call “UnSAFe holes”, i.e. places where we had weak, old, or inconsistent methodology, relative to our evolving, current understanding and related courseware. (Even as a toddler, our baby has some legacy code. Does yours?)

We were working at the Team Level, where we had some early, older descriptions, prior to the fuller evolution of SAFe. On review, this caused us to capitulate to the need to create a new, and more expressive, SAFe ScrumXP graphic (which we euphemistically call the “Little Picture”), which describes activities and artifacts at the team level, and which appears in the Figure below.

This graphic also communicates some upcoming BP release 2.5 artifacts, including separate Team and Program PSI objectives, the Quality Icon, and a new representation of the teams backlog (as it is identified during Release Planning). This new graphic will play a significant role in SAFe proper, as well as Scaled Agile’s Leading SAFe and SAFe Scrum XP courseware.

Then, based in part on the broader context we communicate in this graphic, we rewrote, or at least significantly updated, SIX articles:

• Team Backlog. Now with the new graphic, better illustrating the program’s (ART) context
• Iterations. Now including estimating, velocity, and normalized story point estimating.
• Team Planning, Team Demo, Team Retro and System Demo

Honestly, we had hoped to work further on the next release in the past two weeks, but sometimes you have to take the time to stabilize your code base before you put additional weight on it. Otherwise you can’t really scale.

I admit to having some frustrations with the amount of rework we felt compelled to do, and it must have been obvious to those around me, for when I came into my office the next day, the following sticky was on my door.

(Thanks Alex!)

My friend and colleague, Gil Broza, is interviewing me for his Individuals and Interactions virtual training event. My topic? “Focus Keeps You Going.”

If you read my personal kanban series a couple of weeks ago, you saw how my focus kept me going. Even with a big interruption last week, due to a death in the family, I was able to maintain my focus, because I knew exactly what I had to do, to finish my work, to get ready for my trip today.

Gil has other great people in his event: Doc List, Ellen Gottesdiener, Mary Gorman, David Spann, Christopher Avery and Bob Schatz might be names you recognize. How about Rick Ross? David Spann? Caren DesBrisay? You might not recognize these names, and you should listen to what they have to say, too.

Check out Gil’s Individuals and Interactions training. Sign up. It’s a steal.

A few thoughts on what I think works for running a user group:

Circa 2013, if you want to organise a user group, just use Meetup:

• It provides cross marketing to similar groups for you;
• It makes it easier to coordinate with other groups by showing events occurring on any particular day;
• It pretty much takes care of everything except for discussions / mailing list which are frankly woeful

In general, predictability helps.  The more regular you make it, the easier it is for people to plan to attend.

Run events on a regular cadence.  So, for example, an event roughly the same time every month.  I tend not to be too strict about this but I know other groups will pre-schedule the events in advance.  I'll usually schedule at most a month in advance.

Try to use a regular location.  This can sometimes be difficult, especially if you vary the types of events, but it makes it easier for regular attendees to know where to go.

Avoid using boring offices, pubs and similar are more socially conducive... however, if you want to run activities, offices tend to be better.

Activities are good, lectures are boring.  This is more my preference for groups I facilitate.

Provide food... that's not pizza.  Again, this is more my own preference.  Pizza is a very cost effective meal option but it gets boring when every user group serves pizza.  I prefer to mix it up with alternatives.  I use Menulog and I assume there are similar services outside of Australia.

Beginner sessions will always attract more people (there are always more novices than experts) but be careful...

Beginners show up to interact with more experienced practitioners.  Experienced practitioners will tend to leave if all you have are boring introductory presentations.

Perhaps an obvious point... famous visitors tend to attract a lot more people... so pay attention to who's visiting and just ask them if they'd like to drop by.

"Es sind nicht die Dinge, die uns beunruhigen, sondern unsere Sicht auf die Dinge." Seneca

Eine Szene aus einem Training für Manager im Scrum-Kontext. Auf der Themenliste aus der konkreten Führungspraxis stand der Satz: Wie motiviere ich mein überlastetes und gestresstes Team?

Im Fallgespräch erzählt der Teamleiter, der mit seinen vier Mitarbeitern für die Qualitätssicherung im Unternehmen zuständig ist, dass seine Mitarbeiter von den ständigen Unterbrechungen bei ihren täglichen Vorhaben genervt und immer mehr demotiviert sind. “Kaum eine Aufgabe können wir kontinuierlich zu Ende führen, immer gibt es höhere Prioritäten, durch Kunden, Management oder den Product Owner. Die Tage sind zerrissen durch spontane, unvorhergesehene Situationen, die es uns schwer machen, gute Arbeit abzuliefern. Der Druck ist groß und die Ressourcen sind knapp. Veränderungen aus dem Umfeld sind in absehbarer Zeit keine möglich. Und so quälen wir uns über die Runden und sehen irgendwie kein Land. Trotzdem machen wir immer noch einen guten Job, aber wie lange noch? Wie halte ich in so einer Situation meine qualifizierten und guten Leute bei der Stange, wie motiviere ich sie?“

Während er mir und den anderen Teilnehmern seine Geschichte erzählt, wirkt auch der Teamleiter selbst gestresst, hilflos und deprimiert. Mehrere Kollegen kennen das Erzählte aus ihrer Praxis und bestätigen ihn verständnisvoll in seiner Not.

Ein Bild sagt mehr als tausend Worte

Ich fordere ihn auf, sich mal ein Bild, eine Metapher für sich und sein Team zu überlegen. Er braucht nicht lange und bringt als sein Teambild den Notarzt. Er beschreibt das Bild: „Wie wir muss der Notarzt permanent ohne Vorwarnung zum Einsatz. Manchmal von einem direkt zum anderen. Er hat immer Probleme vor sich, wenn er ausrücken muss. Trotz hoher Kompetenz sterben ihm oft die Leute unter den Händen weg, weil er nicht genug Zeit hat. Oder sie sterben trotz aller Bemühungen später im Krankenhaus. Irgendwie ist seine Arbeit doch meist Stückwerk. Dann muss er auch noch ellenlange Berichte schreiben und ist im schlimmsten Fall an allem Schuld. Das ist doch deprimierend und total unbefriedigend und genauso geht es uns“.

Immer noch ist er deutlich wahrnehmbar in seinem Defizitzustand, es geht ihm nicht gut, er wirkt ratlos und resignativ.

Ich bitte ihn nun, sich doch mal ein positives Bild zu seinem Team und der Arbeitssituation zu machen. Er überlegt lange hin und her, es arbeitet in ihm, aber er kann keine positive Bildmetapher entwickeln. „Mit fällt da wirklich nichts ein, ich bin völlig blockiert. Da gibts anscheinend einfach nichts Gutes bei uns“, ist sein Fazit.

Nun frage ich ihn, ob ich ihm ein positives Bild anbieten darf, das aus meiner Sicht auch eine Möglichkeit sein könnte seine Teamsituation zu betrachten und einzuordnen. Er stimmt, leicht skeptisch, zu.

Ich entwickle folgendes Bild für den Teamleiter:

„Stell Dir vor, Dein Team ist eine hochprofessionelle Bergführermannschaft, deren tägliche Aufgabe es ist, Menschen aller Art sicher auf hohe, steile, ja auch gefährliche Bergriesen aller Höhengrade zu begleiten. Alle Deine Spezialisten beherrschen ihr „Handwerk“ perfekt, sind optimal als Team aufeinander eingespielt und kennen ihren Job genau. Ihr liebt eure Aufgabe und eure Kunden. Gut vorbereitet und hoch motiviert beginnt ihr den Aufstieg. Ihr kennt die Routen genau und arbeitet routiniert. Trotzdem ereignet sich immer wieder Unvorhergesehenes. Das Wetter wechselt plötzlich und zwingt zum Biwak, gefährliche Gerölllawinen erfordern Routenwechsel, Kunden verletzen sich und müssen ins Tal zurückgebracht werden, oder sie geraten in Panik, sind unzufrieden und belasten die Gruppe, usw. Die geplanten Zeiten können nicht immer eingehalten werden. Manchmal kommt es zum Abbruch und es muss ganz neu gestartet werden. Dein Bergführerteam löst die Probleme kompetent und gelassen unter Deiner engagierten Leitung. Bei allen Hindernissen erreichst Du mit Deinem Team und den Kunden (fast) immer die Gipfel. Dann genießt ihr den „Sieg“, freut Euch über die Anerkennung der Kunden und seid immer aufs Neue begeistert vom herrlichen Ausblick auf all die Gipfel, die ihr in Zukunft noch bezwingen werdet. Ihr wisst, dass es kaum eine Situation gibt, die ihr nicht engagiert angehen und lösen könnt, wenn es darauf ankommt. Das zeichnet Euch als Spezialteam aus, das ist Eure Mission und darauf seid ihr auch richtig stolz. Ihr freut Euch auf die nächsten, sicher nicht einfacheren Aufgaben und gebt Euch untereinander Feedback, was läuft und was man verbessern könnte, um Euch als Team zu optimieren.”

Schon bei den letzten Worten meiner Bildbeschreibung wirkt der Teamleiter deutlich entspannter und kommt aus seiner negativen Haltung heraus. Folgender Dialog entsteht (leicht gekürzt):

Frage: „Wie ist das jetzt im Moment für Dich“?

Antwort (mit fester Stimme): „Das klingt ganz  gut, so kann man mein Team und seine Arbeitssituation tatsächlich auch sehen. Und vieles stimmt tatsächlich, wenn ich es genau betrachte.”

Frage: “Wie geht es Dir denn jetzt mit dem neuen Bild?”

Antwort: „Prima, ich fühle mich optimistischer und gestärkt, irgendwie ein ganz positives Gefühl.“

Frage: „Stell Dir vor, Du gehst mit diesem positiven „Bildgefühl“ an Deine Arbeit, was würde evtl. anders sein als vorher?“

Antwort: „Das hätte sicher einen gute Wirkung auf meine Mannschaft, ich lass mich immer wieder zu sehr runterziehen.

Frage: „Nimmst Du das Bild mit, und probierst mal aus, ob Deine neue Haltung tatsächlich seine Wirkung tut?“

Antwort: „Ganz sicher, ich denke ich hab was begriffen, was für mich als Führungskraft ganz wichtig ist. Und ich werde mir ein tolles „Bergbild“ als Merker besorgen.”

Innere Bilder – das sind all die Vorstellungen und Szenen, die wir biographisch (von Kindheit an) gespeichert haben und die unser Denken, Fühlen und bewusstes/unbewusstes Handeln in hohem Maße mitbestimmen. Wenn sich Menschen bildlich etwas vorstellen, sind die gleichen Hirnbereiche aktiv, wie wenn sie es tatsächlich tun. Im Sport wird das seit langem erfolgreich be- und genutzt. Innere Bilder sind im Gehirn abgespeicherte Muster, die wir meist unbewusst benutzen, um uns zu orientieren, Situationen zu analysieren, zu bewerten und unsere Handlungsimpulse danach auszurichten. Je länger sich Menschen z.B. in für sie negativen Bildervorstellungen aufhalten, umso mehr verfestigt sich dieses Bild und seine Auswirkung auf Denken, Fühlen und Handeln. Innere Bilder können uns blockieren, oder aktivieren, können uns ängstigen oder Mut machen und motivieren. Bilderprozesse sind auf alle Fälle eine wesentliche menschliche Ressource, um das Leben und seine Anforderungen zu gestalten.

In Anlehnung an einen Blogbeitrag von Boris Gloger vom 18. Februar 2013 kann gesagt werden: „Führungskräfte sind konstruktiv, nicht destruktiv.” Sie müssen um ihre besondere Wirkung auf ihr Team wissen und durch Selbstwahrnehmung, Selbstreflexion und ihre mentale Einstellung ihren Mitarbeitern gute, positive, stärkende „Bilder“ vermitteln, auch wenn es manchmal schwer fällt. Den Einfluss, den die mentale Verfassung von Führung auf Teams hat, wird in der Regel unterschätzt. Für Motivation, Engagement und Arbeitszufriedenheit, besonders in schwierigen Situationen, ist dies zweifellos oft entscheidend. Dieser Beitrag soll Mut machen, „das eigene Bild“ einer schwierigen Situation zu erkunden, dessen evtl. kritische Wirkung wahrzunehmen und sich ein neues, unterstützendes Bild zu gestalten und den Unterschied zu testen.

Übrigens: Der Teamleiter überlegte zum Ende des Trainings, dieses Bild mit seinem Team im nächsten Meeting zu besprechen. Er kann sich gut vorstellen, dass auch seine Kollegen eine neue Perspektive gewinnen und so mit einer anderen, lockeren Einstellung an die Arbeit herangehen.

Tipp: An der eigenen Einstellung arbeiten und mit dem Team zu neuen Erfolgen aufbrechen – Scrum Supplements sind die Krafttrainings für die Veränderungsarbeit mit Scrum. Nähere Infos und alle Termine gibt es hier.

Related posts:

1. Führung in Scrum | der Manager | Verhalten | Teil 2
2. Führung in Scrum | Manager | Teil 4
3. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster Team gemeinsam meistern Teil 4

Experimentation is a powerful learning tool. When I was young, I performed scientific experiments by mixing chemicals together to see what they would do. I learned that most random concoctions from my chemistry set would make a brown liquid that was often hard to clean out of a test tube. I learned that sometimes they would create very smelly brown liquids. These were not really experiments, however, and I didn’t really learn from them. Instead, these were activities and I collected anecdotes and experiences from them.

The scientific method rests on the performance of experiments to confirm or deny a proposed hypothesis. Unless you can propose a hypothesis in advance, you cannot design an experiment to test it. Until you test the hypothesis, you haven’t really learned anything.

“In general, we look for a new law by the following process: First we guess it; then we compute the consequences of the guess to see what would be implied if this law that we guessed is right; then we compare the result of the computation to nature, with experiment or experience, compare it directly with observation, to see if it works. If it disagrees with experiment, it is wrong. In that simple statement is the key to science. It does not make any difference how beautiful your guess is, it does not make any difference how smart you are, who made the guess, or what his name is — if it disagrees with experiment, it is wrong.” — Richard Feynman, The Character of Physical Law

When we estimate how long it will take, or how much it will cost, to implement a desired amount of software functionality, we create a hypothesis that we can test. Our hypothesis may not be of enduring and universal value as a hypothesis that predicting physical laws, but it may still be extremely valuable to us.

For example, suppose we have a number of features we’d like to get into our next software release. And suppose we have a date in mind for that release, and a team ready to work on it. We could then ask that team to estimate the features relative to each other, bucketing them into groups of similar sizes. We could also ask them to estimate how much bigger (or smaller) are the features in one size group than the features of another. If this team has previous experience working together, they might be able to guess how long one feature might take to implement. Otherwise, they might just take a guess at it.

I would expect these numbers to be simple, with only one or two significant digits. After all, we don’t have much data to base them on. Their precision should not pretend that we do.

If we were practicing a plan-driven serial software development cycle, we might treat these estimates as promises and try to manage the work to meet them. In such case, I would expect them to have padding for the unknown, and higher precision to hide the fact that they’re padded guesses.

Using an empirical software development approach, we’ll instead treat this projection as a first hypothesis. When we finish the first feature, we’ll have some better data on the rate at which we’re progressing, and can project into the future with a bit more confidence. Does this data confirm our hypothesis of when we’ll be done?

This experiment helps us make decisions. If completing the features by the target date looks unlikely, we’ll want to take drastic action. Perhaps we’ll eliminate some features, or make them all simpler, in order to trim scope and achieve some success. Perhaps we’ll decide to cancel the project altogether, cutting our losses with only a fraction of the budget spent.

If the target still looks feasible, we can continue the experiment. We’ll still have uncertainty about both the rate of progress and the size of the work, but we can reason about those uncertainties. Are our errors in sizing likely to be additive, or random? Is the current rate of progress sustainable? Is it depressed because of one-time startup work? Or is it optimistic because we’ve been cutting corners?

Poorly handled estimation is a means to fool ourselves, but handled with care, it gives us tools to experiment and learn.

This June I will be running the Property-Based TDD workshop at the XP 2013 conference in Vienna and, with Keith Braithwaite, at SPA2013 in London. This is a hands-on programming workshop to explore how property-based testing influences the TDD process and the designs it produces. The TDD/BDD community has not embraced property-based testing, despite tools having been available for some time for most programming languages. TDD practitioners "triangulate" a property of the system by testing it against multiple examples, selected manually. This is not ideal. Triangulation does not explicitly define the property being tested, giving little scope for automating the selection of test data. People reading a test must infer the property from the data and name of the test, which can be difficult. It is easy to write tests with poor condition/decision coverage. The property-based testing literature has focused on testing for quality assurance. It does not describe property-based testing tools being used to drive development, focus attention, measure progress, and obtain design feedback. A notable exception is Saff & Boshernitsan's article on JUnit Theories, The Practice of Theories: Adding "For-all" Statements to "There-Exists" Tests. In this workshop we will investigate the intersection of TDD and Property-Based Testing. How do we go from examples to properties? Must we start with examples and generalize to properties, or can we start with properties in some cases? How do we change properties as the system grows? Do we start with general properties and specialize them, or specialized properties and generalize? How does that compare to adding examples? Can property-based testing drive design? If we focus on properties, do we get different designs than if we focus on examples? Are some design styles easier than others to describe in terms of properties? Does property­-based testing work better when working top­down/outside-in or bottom­up/inside-out? Note that this is a workshop, not a tutorial. I don't know the answers. I'm hoping we can find some out together. The workshop is suitable for developers with experience of Test-Driven Development. If you want to participate, you'll need a laptop or to find someone to pair with who has a laptop. You can use any language you like, as long as you can find a property-based testing library for it and somebody to pair with. People have used Python, Ruby, Java and C#. It would be great to see people using Haskell, ML, F# or Scala. If you can, try doing Keith Braithwaite's TDD As If You Meant It exercise beforehand, so we can compare and contrast doing the same exercise with different kinds of testing.

It’s May. We’re almost done with half the year, and I haven’t stuck with my publicly declared commitment to be more regular with my writing. This is not an apology, though. It’s a declaration of peace, made from me to me, and maybe it’s even a bit of a pat … Keep Reading →

Guest Blogger Vince Mills

In many companies, agile software development is misunderstood and misreported, causing taxation increases, higher volatility in Profit and Loss (P&L) statements and manual tracking of programmer hours. One large company’s confused finance department expenses all agile software development and capitalizes waterfall development; projects in this company that go agile see their headcounts cut by 50%. This discourages projects from going agile.

Scrum’s production experiment framework can align well with the principles of financial reporting. In this article, the author explains the basics of capitalization and expensing, and offers a financial framework for capitalizing agile projects that can be understood by both accountants and agile teams.Software development is an investment in the long-term future. Some software development projects are not long-term investments; it depends on whether the software remains an asset. Agilists should learn proper capitalization and teach their colleagues. Companies can usually save on taxes, hire more developers and create value more rapidly when they capitalize software development correctly.Companies can gain tax advantages by capitalizing software development; by deferring costs they typically offset more taxable revenue and gain more interest income.Corporate agilists need to help finance departments capitalize agile software development properly. ScrumMasters and agile department heads who understand capitalization and depreciation can generate millions in tax savings. Responsible agilists must work directly with their own corporate finance departments and auditors to craft acceptable capitalization processes.Because recommended accounting practices ignore Agile, the article discusses how to classify costs as capital or operational expenses and gives guidance on how to make the transition from waterfall to Agile in a way that pleases management, accountants and auditors.Making the case for agile capitalization will reduce your company’s tax burden, increase available funds for engineers, and make your auditors happy.

First, is a Scrum Team organized?

Well, a good Scrum is more adaptive, probably, than it is ‘organized’.  Of course, we can debate the meaning of these words, but during a day or during a sprint, or during a release, I usually would rather that the Team be adaptive, than that they follow an organized plan. As one example.

This is one small reason that our Scrum course is not organized in a strictly logical way.

Second, why do Scrum Teams fail?

Well, there are many reasons. One key reason that is not true: They were not intellectually able to fight through the complexity of the explicit knowledge around the bare framework of Scrum.

In fact, the bare framework of Scrum is very very simple. (On purpose.)  And understanding the explicit knowledge around that is quite easy.

Hence, we are not worried that we need to organize the course so that the attendees build in their minds ‘complexities upon complexities’ about Scrum.  If Scrum were complex, for example, like the Calculus, then we would have to organize the course a different way.

Again, Scrum is ‘holistic’ or interdependent.  One cannot understand one part of Scrum without understanding how it works with or plays with another part of Scrum.  ‘No man is an island’ as John Donne famously said.  So, we like to continually weave from one thing to another, so that this weaving starts to be embedded in the ‘back’ minds of the attendees.

So, one of the key problems is tacit knowledge. Getting the tacit knowledge and all that that means into their heads.  But, honestly, not just into their heads, but their hearts, their souls, their guts, their bodies.

And one of the big problems is that the attendees, or many of them, resist intellectually.  So, as in Zen, we have to confuse the intellectual mind in order to enable real learning to happen faster.  Or, as the Army says, we have to break them down in order to build them back up again.

We have to ‘go around’ or ‘get behind’ the intellectual resistance that is common to just about all of us. So, one technique is to do exercises. But not following a highly logical flow to the course is another technique. Surprising the attendees (in small ways) is another technique. Humor is another technique.  Improvisational exercises is another technique. Food is another technqiue.  Addressing them, and getting to know them, as a person is another technique.

For some, our techniques (and there are actually many) are…umm, disconcerting. If one is the organized, intellectually rigorous, ‘it is all about thinking and logic’ type of person, it can feel a bit uncomfortable.  But if one has at least an intellectual understanding or some real experience that says that people and real life do not always follow our pre-conceived intelectual notions, then it is not so uncomfortable.

So, I admit that the course to a new person, or at least a few, can feel uncomfortable. (Actually, my impression is that most people enjoy it. About 95%.  But not all.)

If, in the course you tell me you have that feeling, then I will offer some advice. First, that we will address the topics, or most of them, that are on the one-page (two-sides) outline of ‘Scrum’ we hand out (it is really more than just Scrum).  And we will follow, mostly, the outline on the website. (Except not in that order.)  And that we will follow the slides, pretty much sequentially.  Except that we will cover additional things that are not shown on slides.

We have a strong confidence that most real learning is not logical. It happens in the sub-conscious mind, where a whole bunch of experiences are ‘put together’ by the brain into a ‘logical’ way of looking at the world.  Assembled into a pattern or set of patterns. And we are forcing your brain to break down old patterns, and rebuild all that ‘stuff’ into new patterns. And we have a strong confidence that all of out attendees can do that.

And we also know, sadly, that many are so much ‘controlled’ by what we call ‘waterfall ideas’ that they will not be able, after only 2 or 3 days, to really replace the waterfall patterns with agile/scrum patterns.  So, we are sad when we do not succeed in this way.  It does happen.

Would we succeed better if we presented things in a more organized, more logical way?  Well, in a very small sense with a very few people, they might at least say ‘it was a good logical presentation’.  And they, that small group, would feel better.  But we are completely convinced that, if you look at the overall results, we would be much much lower.

Remember that our goal is not teaching. Nor learning. Nor even action by the attendees. Our goal is to achieve real results with Scrum. For the person, for that person’s team, and for that person’s customers. One never will achieve real results with merely a ‘logical understanding’ of our work.

We are not after explicit knowledge. We are after ‘a sense of urgency’ and the tacit knowledge that leads to successful results.

I wish you every success in having fun in achieving real results.

I participated in Lean Startup Machine in Sydney in April 2013.  Here are a few things I noticed and thoughts I had...
Three customers Sebastien Eckersley Maslin, CEO of BlueChilli, talked about his 3 customers concept:

1. Target Customer: Who has the direct problem you're solving?
2. Scale Customer: Who deals with your Target Customers in bulk?
3. Strategic Customer: Who can derive more value from your assets than you can?

This was from the perspective of exit strategy which I generally don't care for.  However, this concept is still interesting if you see this as a way to understand the bigger picture of what happens when a product / service is introduced in a market place.
What's your larger mission? Jodie Fox, co-founder of Shoes of Prey, pointed out the importance of having a larger mission, even a potentially impossible mission, but one that provides a consistent direction.  For example, for Shoes of Prey this is "Every woman deserves a perfect shoe".  This was in response to a few teams that had "pivoted" to perhaps not as interesting concepts.

This reminded me of The Toyota Way and the importance of having a Long-Term Philosophy.
Teach a way of thinking or find another successful startup? Is the purpose of events like Lean Startup Machine to teach a way of thinking? Or is it to find another successful startup?  I believe it really should be the former.

Structuring as a competition does not reflect that purpose.

Instead of a competition, the event would focus on teaching concepts, basic assumptions, principles, and tactics like Magic Tests, Concierge MVPs, selling approaches, etc.

Teams would be encouraged to identify problems that could be explored within the context of the event (i.e., on a weekend) AND/OR the event would be scheduled to allow different types of problems to be relevant.

Teams would be smaller so that participants would actually have to attempt all the skills themselves rather than rely on another team member.  Perhaps they would be 1-person teams to ensure that everyone has a direct understanding of what skills you actually need in the real situation, and therefore who you'd want on your team.  People would be exposed explicitly to what their strengths and weaknesses are.
Validation Board or Business Model Canvas? Lean Startup Machine uses a Validation Board to structure our hypotheses and tests.  The focus is on testing problem-solution fit.  I like the focus of the board, but I miss the bigger picture aspects of the overall business model that you can see with the Business Model Canvas or even the Lean Canvas.  I think I'd rather use either of those to capture the overall business hypothesis and switch to a Validation Board like structure after the riskiest assumption was identified.

The most popular Agile certification! This two day course gives you the foundations to be an effective ScrumMaster and contributes towards the requirements of the Scrum Alliance’s Certified ScrumMaster program. Delivered by Berteig Consulting’s own Mishkin Berteig!

By successfully completing this course you will be able to:

• Remove obstacles that prevent teams from becoming high-performance.
• Enable a team to follow the Scrum process to deliver great products and continuously improve their quality.
• Describe Scrum to others including roles, meetings, artifacts and principles.
• Fulfill the requirements of the Certified ScrumMaster program.

Days: July 10, 2013, July 11, 2013

Location:

Audience: This course is ideal for those who desire to create high-performance product development teams. Team leads, project managers and functional or line managers all can benefit from understanding Scrum’s amazing transformational power and the critical role of the ScrumMaster. If you are a member of the Project Management Institute, this course counts for 16 PDU’s and as part of the requirements towards the PMI-ACP designation.

Price: $1400.00

Contact: Valerie Senyk at 1-905-868-9995

Email: valerie@berteigconsulting.com

Link to Register: http://www.worldmindware.com/Certified-ScrumMaster-Mississauga-July-2013

People have two styles  when they prepare to take action and meet their goals: The "Toward" and"Avoid To".  These were revealed to me by a great chat with Sylvaine, a successful coach of "Well Being at Work" in France. She says that it takes both profiles to effectively achieve the goal. That turned on a light in my mind  it's not only about individual profiles it is also about cultures : they are also deeply anchored in the "toward" or "Avoid To" style to see the wold evolving."Toward and "Avoid To"It is unnecessary to write long essays or boring blog posts to explain what these two profiles are about.The "Toward" way is "get-into-action" driven: look-forward,  never forget what is most important for you and go-for-it. Everything else are details that can be dealt with on the wayThe "Avoid To" way is focused to protect the "route that leads to the goal" of the different obstacles. Forecasting potential problems is a valued activity for the "Avoid To" styles . They like to have the most exhaustive risk analysis as one can get. 
OppositesIf both profiles are helpful to achieve a common goal, the challenge is huge. These two profiles tend to have little natural appreciation for each other. The "Toward" people tend to consider the "Avoid To" people ineffective,  unwilling to take responsibility and somehow... "spoiled" and "lazy".The "Avoid To" people tend to consider  the "Toward" people as bullying, bossy,  somehow ... rude and definitely lacking respect to anyone else in the room.So put these two together to nicely work together, yeah! A piece of cake! And still, let's go for it.
Individuals and Cultures create their personality through stories
"Toward" and "Avoid To" are rooted in our culture and they shape our way to see the world. Beyond individuals,  some cultures value a "toward" posture and others that are more "Avoid to". History is full of examples of tensions between nations that base their culture on the 2 different profiles.  Each group and organization is creating a culture, sometimes without really being aware of.  We mention the "company culture", and we may have some hard time to define it. Just like for different people, what we really have at hand to describe culture are its stories. The most reliable way to reflect a culture are stories.  These stories tell you, among other things,  if the group (company, people...) culture is "Toward" or "Avoid To" driven. Here is a little example:
The Salt Block
A very popular Romanian tale* starts like this :

"Once upon a time there was a young peasant . He was happy : he worked hard the land and the land was generous to him. He was married to a young loving woman that kept the house bright and have filled his life with joy when she gave birth a couple of weeks ago to their son, who was strong and in good health.
That summer sunny day he was coming back home from the labor of the field, when he hears scaring cries in the house. Full of panic, he hurries home and enters the house. His surprise was not little when he sees his young wife and her mother bounced over the baby's cradle, crying out loud as if the baby were dead. For God's sake, the baby seem to be in perfect shape , only scared of womens' cries.
"What is happening here, women?", asks the young man
"Oh, my dear husband,  a cruel fate is threatening our son!"
"Oh Holy God", says the man who starts to be really frightened, "what is that?"
"You see the big heavy block of salt on the top of the drawer?"
"Well yes..."
"And the cradle that is near the drawer right under the block of salt?"
"???!!", the young man's fright turns into perplexity .."And...?"
"Well you have a heart made of rock, you, what if the salt block falls on our baby and kills him?" cries the young woman that surrenders in the arms of despair.
The young man is shocked by his wife's stupidity. He decides to leave home and never  come back unless he finds people in the world that are more stupid than his wife. 
What does this story value? Would you recognize one of the two profiles here? If you think you have the answer, wel, actually, it might not be that simple ... 
You can change only one person : Yourself
If you'd ever want to know what is the end of the story, I'm not sure there is any English version available, so let me tell you that it has a happy end : The young man is coming back home, he encounters a lot of people that have a ... more astonishing way to approach life and work than his wife.Beyond reflecting a "Toward" profile , this story's insight is about learning to live with the others, even if you start by don't having a clue about their behavior ( even feeling a hard disapproval about it) . The "Toward" and "Avoid To" profiles are opposite. And honestly they don' appreciate each other.  Making the two profiles working together is not about a super-wonder "someone" above taking some smart move to make the mixture work, it is about myself (yourself) realizing the gap in seeing the world as it is. And trying to respectfully live with it. Just like the young man that came home and lived happy ever after with his family. As long as historical research reported, there was no dead baby ;-) .
Thank You
Many thanks to Sylvaine that inspired this post. If you can read French, you'd really love her blog 

*The original name of the tale is "Prostia Omenească" by Ion Creangă

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: KNOW THYSELF

“Using self-awareness and self-knowledge for self-management seems to be key in becoming an effective leader.”

Running time 26:38

What instruments have you experienced that have been helpful to you? When has really good self-awareness and self-knowledge helped you self-manage as a leader? If you’ve experienced the Hogan, tell us about it. We’d love to hear your stories.

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – Using assessments in organizations to develop self-awareness and self-knowledge to become effective leaders.
1:55 – Introducing the Hogan assessment – richer, more subtle and provides more nuanced information.
5:56 – The Hogan assessment considers three parts: individual values, leadership potential and challenges or derailers.
13:12 – Comparing the Hogan assessment with the Strengthsfinder by Gallup.
19:54 – One differential aspect of the Hogan assessment – it can be used to map teams.
23:50 – Assimilating assessments like the Hogan in academic programs.

Resources
Hogan Assessment
Myers-Briggs
StrengthsFinder

Photo Credit: Werner Kunz via Compfight cc

I’ve been thinking lately about the ways that different authors explain OOP. I’ve drawn a little diagram that I would like to share with you.

The sources for this are, in no particular order:

• Eric Evans, DDD Reference
• Ivar Jacobson, Object-Oriented Software Engineering
• Peter Coad, Archetypes, Color, and the Domain-Neutral Component
• Rebecca Wirfs-Brock, Characterizing Classes
• Steve Freeman, Nat Pryce, Growing Object-Oriented Software
• Vaughn Vernon, Implementing DDD

Each of these authors has a perspective I find useful. I would love it if there was a comprehensive, single model, but so far I can’t see how to systematize them.

It gets weirder when you start collecting design principles… I might do a mind map of those some day. Somehow I can see how SOLID and GRASP (for instance) are compatible. They are pointing in the same general direction, but from different angles.

Recently I have been asked by several customer organizations to help them to understand how to account for the expense of agile software development. In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations. The details of accounting rules vary between countries, but the fundamentals are common.  In order to get properly account for the costs incurred by software development teams you need to keep track of the amount of work performed and the type of work performed to develop a given solution. Time tracking doesn't have to be complex: at one customer developers spend less than five minutes a week capturing such information.

 

Why is Time Tracking Potentially Valuable?

There are several financial issues to be aware of:

• Capitalization. For public companies capital expenses (CapEx) can potentially boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization's taxes for that year.
• Matching. One of the goals of good accounting is to accurately reflect the net income of the enterprise and to prevent income manipulation or "smoothing". As such a key tenet is the principle of matching revenues with the appropriate expenses. For software this means that we expense the cost of the software over the lifetime of the asset against the income at that time. An implication of this is that capitalizing software development, when appropriate, before the software goes into production clearly violates the matching principle since there is no benefit of the asset until such time.
• Tax Credits.  In some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature.

The point is that the way that a software developer's work is accounted for can have a non-trivial impact upon your organization's financial position.

 

What Do Agilists Think of Time Tracking?

So, I thought I'd run a simple test. Last week on LinkedIn's Agile and Lean Software Development group I ran a poll to see what people thought about time tracking. The poll provided five options (a limitation of LinkedIn Polls) to choose from:

• Yes, this is a valuable activity (33% of responses)
• Yes, this is a waste of time (39% of responses)
• No, but we're thinking about doing so (2% of responses)
• No, we've never considered this (18% of responses)
• I don't understand what you're asking (5% of responses, one of which was mine so that I could test the poll)

The poll results reveal that we have a long way to go. Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity. When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars. Looking at it from a dollar per minute point of view, it could be the highest value activity that a developer performs in a given week.

The discussion that ensued regarding the poll was truly interesting. Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking. Some comments that stood out for me included:

• It's a colossal waste of time unless you're billing a customer by the hour.
• We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
• I think the *most* pointless example was where the managers told us what we should be putting in.
• One day we will move past the "just do it" mentality and have some meaningful conversations and the reasons for what we do.
• In my experience time tracking is a massive waste... of time. It's a poor substitute for management.
• Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
• Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports. And they do not believe that Management can resist the temptation to use task hours as a measure.

I think that there are several interesting implications from this discussion:

1. Agilists need to become more enterprise aware. It's clear to be really effective that agile delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they're doing.  In Disciplined Agile Delivery (DAD) this is something that we refer to as being enterprise aware.  There's far more to enterprise awareness than understanding pertinent accounting principles, for interest disciplined agile teams work towards a common technology roadmap and common business roadmap, but appreciating why time tracking is a potentially valuable activity would be a good start.
2. Management needs to communicate better.  It's also clear that management needs to communicate more effectively regarding why they're asking people to track their time. To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they're asking for.
3. Management needs to govern more effectively. Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result).
4. Time tracking should be streamlined.  It was obvious from the conversation that several people worked in organizations where the time tracking effort had gotten completely out of hand.  Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much.  Over the years I've helped organizations design measurement programs and I've seen a lot of well-intention efforts become incredibly onerous and expensive for the people they were inflicted upon.  I suspect it's time for a reality check in some of these organizations people were alluding to.  A good heuristic is that for any measurement you should be able to indicate the real cost of collecting it, the use(s) that the information is being put to, and the value resulting from those uses.  If you can't quickly and coherently do that then you need to take a hard look at why you continue to collect that metric.  The lament "we might need it one day" is a symptom that you're wasting time and money.
5. Agile rhetoric is getting in the way.  Some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and stand up meetings may be preventing people from becoming enterprise aware because they believe that all of their management needs are being met by them.
6. You may be missing out on the benefits of time tracking.  Many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.

 

Parting Thoughts

Disciplined agilists are enterprise aware. This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization. In the anecdote I provided it was clear that many agile developers believe that an activity such as time tracking is a waste when that clearly doesn't have to be the case. Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization.

Granted, time tracking on an agile project team is nowhere near as sexy as topics such as continuous integration (CI), TDD, the definition of done, continous architecture, or many more.  But you know what?  Although it's a mind-numbingly mundane issue it is still an important one. 'Nuff said (I hope).

I’ve had a love-hate relationship with two-phased commits during my years with messaging. Even if MSDTC was free to set up, it doesn’t come free in terms of throughput. Most people run into 2PC in messaging because because queueing systems and databases are two different resources, and therefore don’t participate in the same transaction. Ideally, I’d have all three participants either succeed or fail together:

Since the queues in this picture are different resources than the database, I need to involve a third party, or transaction manager, to coordinate transactions between these three resources.

DTC, when it works, works really well. It’s much, much easier to not care about the consequences of a lack of coordination. In fact, I’d recommend not caring until you actually do care, because ditching two-phased commits does require work. Luckily for us, there are a ton of resources on how to do exactly that!

Most of the time, literature around avoiding 2PC is concerned about an entirely different situation, where I have two separate databases:

We’re doing messaging, which means that it’s typically the consumer of the message that does something against other data stores. So even though we’re avoiding communicating with two databases, it’s still two resources, and thus a need to coordinate!

But again, that coordination comes with a cost. A fairly large cost, in some recent testing we found that overall throughput dropped 80%, or to put it another way, ditching DTC saw a 5X increase in throughput. Five fold!

For some systems, that throughput doesn’t matter much, but for those that have a reasonably high volume of messages, or sensitive SLAs, it’s worth investigating alternative approaches.

General rules of thumb

Like most messaging approaches, the ways of avoiding coordination are right in front of our faces. In Gregor Hohpe’s excellent paper on Starbucks, he points out any real-world system that values throughput over absolute consistency avoids distributed transactions. The basic ideas are:

• Idempotency is king. Get this and you’re halfway home
• Strategies for dealing with downstream effects is a business decision

Idempotency is absolutely required, but it’s not that hard to apply. For some operations, we can rely on natural idempotency. If I’m asked to turn on the light, receiving the request twice means the same outcome – the light is on! For state machine-like systems, idempotency is a bit easier.

For operations that aren’t naturally idempotent (launch the nuclear missile), we’ll need to get a little creative. If we can identify some correlating information from a request (The president called at 9:15 to launch the missile) or just assign some correlation information (The president has issued request #132 to launch the missile), we can simply keep a journal on the receiving side. If it’s expensive to keep a journal around, we can recycle/trim our journals if they get too big.

Downstream effects become more interesting. If throughput is a high concern, we can rely on compensating actions (customer didn’t have enough money, cancel the order) or more journaling. Instead of sending a message immediately, shouting out messages to downstream systems, we can instead just write down in the same persistent store as our other data another journal for outgoing messages.

Once our local DB transaction is complete, it’s just a matter of sending the messages we’ve written down to send out down the line, and crossing them off our list of “sent” messages. And since downstream systems can deal with at-least-once messages through our idempotency guarantees.

How I learned to stop worrying and ditch 2PC

In some current systems, we’re deciding on a service-by-service basis whether or not we want to enlist or not enlist in distributed transactions. It’s still annoying to try and build a system-wide solution (though the event sourcing guys have this more or less in the bag), so until then, I can just use business decisions to guide me one way or the other.

But it is time to let go and stop worrying so much. Honestly, unless your services have downstream side effects, you can safely turn off DTC if your work is idempotent. If you have downstream side effects, there’s a number of paths to choose from. While I’m not saying goodbye forever (still the best solution if it were absolutely free to use), it is time to shop around.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

In one of my AYE sessions, we started by completing a sentence:

Read this aloud. Feel it. Is this the way you’d like to work?

© Esther for esther derby associates, inc., 2013. | Permalink | 4 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh