Technical Debt

Habitable Code / Clean Code

Let's define Habitable (or, Clean) Code as one in which programmers coming to code later in its life can understand its construction and intentions, and change it comfortably and confidently.

Technical Debt would be the work that remains to make the code habitable.
The debt metaphor was coined by Ward Cunningham, to illustrate that like with financial debt, the cost of change grows over time. Instead of money we borrow time. 

when software's technical debt is not paid, bugs come and break its legs

— Ron Jeffries (@RonJeffries) April 28, 2012

Every developer who spent some time with code experienced this: a design that was once elegant turns over time to a big ball of mud, to spaghetti. Complexity grows, and changing the code feels like walking through a mine-field. How do we get back to safety?

What makes us feel unsafe changing code?

Mostly, a culture of laying blame. Fear driven development. Addressing that has less to do with technical debt, but I explore some ideas about safety here. 

What else? Here's a partial list:

• Low automated test coverage
• Late, high cost, infrequent integration testing milestones 
• Failing test cases
• Code anti-patterns (static analysis warnings)
• Low cohesiveness of classes
• High cyclomatic complexity
• Various architectural anti-patterns that make the design hard to understand 
• Known (and unknown…) bugs
• Missing API documentation
• Duplication
• Long methods with deep nesting
• Misleading names and metaphors
• Lack of adherence to coding standards (inconsistent style)
• “TODO” comments

How did we let our tests and code get this way? Could be any number of reasons, but essentially they would fall under these 3 categories:

• Planned decision - being aware that the code needs more work we release anyway due to some constraint but intend to fix the code in the immediate future
• Accidental - and here the big question is do we learn from it and become more competent - or we simply don't know any better
• Reckless - we don't give a damn 

I would assume that the first one is a desired state, where you occasionally take on debt and pay it back before it becomes a big problem. Dealing with the last one is not about tools and techniques - there some deep underlying problem to address. 

But from what I've seen, it's mostly accidental, and here we can improve by learning ways to assess, avoid and reduce technical debt.

Assessing Technical Debt

Some frameworks (like sonar) are good at providing metrics and visualizations of different aspects of technical debt, integrating static code analysis data regarding style, anti-patterns, complexity, duplication, cohesiveness and information regarding test coverage. 

Like any tool - you need to know when and how to use it. I'll let you in on a secret: 

     You don't have to fix all of it 

Remember why we care about technical debt? It increases our cost of change. But maybe there are areas of the code we don't really change that much? 

What we need to care about is code we change often. This is where the mess hurts the most.

Michael Feathers: getting empirical about refactoring.

Because of that attribute, assessing the amount of technical debt is not as important as dealing with it. Some would even say dont waste time tracking technical debt with some very good reasoning.

Preventing New Technical Debt

As a strategy you need to change course - commit to a new behavior. The team needs to take upon itself some new rules and stick to them. If they have a definition of done, this might be a good place to add some helpful practices. But drawing a line, saying "from this day on..." is a good start.

Some concrete practices:

• Test-driven-design
• Group design (whiteboard sessions)
• Education & team agreement (e.g. adhere to „clean code“ practices)
• Pair programming / continuous code reviews
• Continuous integration + automated tests + static analysis tools

A note regarding tools: they won't help unless regressions are visible (dashboards which the team actually sees) with a clear agreement on what we do whenever there's a regression. 

Hint: fix it. Now.

Paying Back Our Old Debt

To reduce debt, you are probably going to identify an area to improve, pad it nicely with automatic tests, and refactor. Rinse, repeat. Since there's always room for improvement you need some way to balance the effort that goes into this kind of work with your need to build stuff. So unless some major rewrites are needed, the most effective, and simple way I know of is what Uncle Bob calls "the good boy scout rule", paraphrasing on "Always leave the campground cleaner than you found it". 
Another option is to set goals based on metrics if you are using something like sonar, but again - this is easy to get wrong and wastefully get people fixing code that's hardly ever touched.

The Curse of Knowledge

So now you know. Its no longer accidental from now on. How did we call not taking action to deal with known technical debt? Oh, right - reckless. 

It might be a hard sell for some stakeholders if you need to make some meaningful investment to change course, but if they care about the future of your product, the sooner you can agree, the better. 

Further Reading

Building Real Software (Technical Debt)

Agile Practitioners 2015

After last year's conference, the guys from Practical Agile decided to "open source" the conference - the conference was community driven by a volunteering steering team. This year the conference offered a full 4-track program under the title "learn something new" making it harder than ever to choose the sessions.

Keynote: Unicorns, krakens and self-organized-teams

a delegation board

A slimmer version of Angel Medinilla (@angel_m) returned to get things going with his high paced, humorously sketched view on the road (and pitfalls) to hyper-performing teams. Some of the notions come from management 3.0 which is not a coincidence, as Angel is one of the M 3.0 trainers. Some topics to follow up on may be the Agile Fluency Model, the "Agile Kaizen" book and delegation boards.

Morning Sessions

Gil on #NoEstimate

Gil Zilberfeld's talk, “To Estimate or #NoEstimate” talked about the #NoEstimate movement, why people want estimates, what are the problems with estimates and what could be useful alternatives.

Meanwhile I missed, among others, Uri Nativ's "Missing Lecture" about the difficult-to-deal-with gap between the agile coach/leader's perspective and the teams' view on the agile change initiative. I love the slides (form and content).


Next, Lior Friedman, talked about code smells, and their less (in)famous cousins: Test Smells. Learning to identify them can help improve the system. After all, TDD is a way to write well designed software. Problems in the tests often tell you of problems in the design, or even in your process.

Afternoon Sessions

Three short sessions:

One of Barak's slides

• Gull Ben-David (from MyHeritage) shared why QA people make good scrum masters
• Ran Deri and Noam Zweig (from CyberArk) gave some insight on their experience dealing with Technical Debt systematically. Interesting mix of tools (such as sonar) and assessment (using a survey by Gil Broza) to actually track, negotiate budget and set goals.
• Barak Benjo (Cisco) gave tips for Agile Testing in a legacy environment

In a session I missed, Yuval Yeret (happy birthday!) gave a talk about an effective way for managing an agile transformation.

"Lean Lens" - observing our results

Andrea Darabos conducted her "Lean Lens" workshop. It is essentially a role playing game each team gets a scenario to play out. Some participants act, simulating the different roles, while others observe, trying to identify the 8 types of waste (better known as the 7 wastes + unused skills).
You can download the game here (developed by @bazila and @ADarabos)
Interesting takeaway - try set up a board in the team room to collect instances of the 8 wastes as they happen, and deal with them in the retrospective. Hey - these are "process smells"!

Meanwhile, Eyal Golan talked about working with legacy code. I was told it was interesting and practical.

The last track session actually had 5 options, because Angel agreed to give an improvised sketching workshop where we practices some basic shapes, faces, stick men, containers, call-outs, etc. That was fun, and it was similar to some of Angel's Drawing 101.
More advanced stuff can be found in learning to sketch on tumblr.

Closing keynote: Claudio Perrone on Popcorn Flow and A3 thinking

Claudio, a.k.a Agile Sensei, described his A3 thinking / problem solving system, and POPCORN flow, which is a kanban board for capturing, planning and tracking change experiments.
Slides here (well, very similar to the ones he actually used). Another interesting concept he described was "job to be done" (JTBD) as an alternative to user stories formulation, focusing on the human need you wish to fulfill. As an intro to the topic, Alan Klement's description of a "job story" is very useful.

There was much more, obviously, but that's what I can share. Great stuff, community!
You can find more here:

• Dror Helper's impressions of the conference here
• Gil Zilberfeld shares some stats (and a creepy photo holding Dalia's disembodied head)
• Twitter handle: #APIL15

Packing List for Your Agile Journey - Change

The Ten Speakers in the Series

Packing List

Today Gil Broza interviewed me about "embracing change", as the 9th interview out of ten hour long interviews in his series called: "Packing List for Your Agile Journey".
Subscribers get the ability to listen live or offline, access to transcripts. Gil asks each speaker to focus on one topic, so the overall series has a great balance of topics for listeners who want advice and ideas for starting or improving an agile implementation.
The topics are: Organizational support, enabling collaboration, feedback loops, whole product thinking, quality, technical excellence, get-to-done mentality, culture, change and values.

Some of the Things We Talked About

Gil asked me about change - how agile helps you deal with change, what types of change do we deal with or worry about, how did we (and still do) change an organization to become agile?
Some of the insights I can now recall without having a transcript of the call:

• People don't really resist change. They resist change that's imposed or seem arbitrary.
• Agile is designed to deal with changes in what you do, and encourage you to change how you do the work. It's less prescriptive about how to change to agile, which is essentially a cultural change
• Understanding and buying into the values and principles of Agile is much more essential than mastering a specific practice or ritual. Going through the rituals mechanically is equivalent to a "cargo cult", and will yield very little improvement, if any.
• Working in a large and distributed organization such as Software AG, there were a few observations:
• Sometimes a cultural difference is felt more after a merger/acquisition, than across geography and nation
• The challenges include quick integration of products, organizational changes (due to M&A), and building and maintaining trust when people are in different locations and timezones
• Having a senior manager who "gets it" and can point the direction and set priorities is invaluable 
• We have a "Change Agents" team who represented all locations, got together and got deep coaching and continued to function as a virtual team. This team was very helpful quickly getting the whole organization to learn the principles and coach people to start experimenting with the process. It also helped building trust across locations.
• We invested much in values, culture, lean principles and teamwork training - more than any specific practice
• Push back if you feel you are about to do something dumb
• A Responsibility stance (Avery) or Being Proactive (Covey) is essential to successfully dealing with change 

I'm likely to update this page after having the transcript to maybe reflect the content a bit more accurately.

More Questions

I'll be happy to get comments on this post from anyone in the audience who'd like to expand on anything I mentioned or ask more.

Habit 2 - Begin with the End in Mind

This is a part of my Introduction to Covey's 7 Habits series.

“Life can only be understood backwards; but it must be lived forwards.”
Soren Kierdegarrd, 1843

Beginning with the End in Mind means...

Imagine you're dead.

Morbid, right? 
Still, imagine it, and imagine what you want people to say about you. It's not a vanity exercise, it's a way to help you reveal what you value as worthy goals to review. It also helps put the daily life busy-work in proportion. Does it really matter if you used every spare minutes doing a great job on some work that, in retrospect, didn't serve any greater good that you are proud of?

Before anything can be physically achieved, it is envisioned. Covey calls it "all things are created twice" - mental creation which precedes the physical creation. The point is, who drives your life? Do you envision your choices proactively, or do you let someone else lead your life?

Personal Leadership

While management is attributed by efficiency and "doing things right", leadership is about effectiveness and "doing the right things".
This Habit is about personal leadership - defining what you value as the right things. Using self awareness, imagination and our conscience we can build a Personal Mission Statement to aim our lives towards. This is a self defining action, building a sense of who you are and what is your role in life.

At the Center

What is the source of security, guidance, wisdom and power in your life?
Covey point various centers he observes people draw on: spouse, family, money, work, possessions, pleasure, friends or enemies, church or self. Putting such things at the center makes you dependent, and Covey points out the option (or, rather, need) of being centered on "correct principles" - deep, fundamental, unchanging truths. As such you try to stand apart of the emotional triggers of a situation and observe options, as described in the first Habit, Be Proactive.

Applications in Software Development Practices

While Covey talks of the ultimate end (death), there are also other ways to apply the same pattern to smaller scopes. Lean pull systems, Agile practices such as test first and even the way user stories are formulated all aim at starting with the required result, value, purpose - and work your way back to the tasks needed to realize this result.

Related Reading

I liked this post Life on Purpose: 15 questions to discover your Personal Mission which actually has a good list of further reading at the end of it.

Habit 5 - Seek First to Understand...Then to be Understood

This is a part of my Introduction to Covey's 7 Habits series.

"No one cares how much you know, until they know how much you care" ―  Theodore Roosevelt

Empathic Communication 

Like any good doctor, diagnose before you prescribe. We learn how to read, write and speak - but what about listening?

Image from a blog by ksa

Most people listen with the intent to reply. They have two modes: 'speak' and 'prepare to speak'. Even when we do listen, our basic instinct is to apply what people tell us on our own experience and biography. "oh, I know exactly what you mean!". When we do that we've stopped hearing. Empathic listening is about understanding others from their frame of reference:

"You never really understand a person until you consider things from his point of view... Until you climb inside of his skin and walk around in it.” ― Harper Lee, To Kill a Mockingbird

Levels of Listening

Try to identify at what level you listen to someone - at home or at work:

1. Ignore or pretend to listen 
2. Selective listening (scanning for key words of your interest)
3. Attentive - focus on the words
4. Empathic - listen to what's being said, and the underlying emotions

Empathy is about understanding emotionally. Don't confuse Empathy with Sympathy. Sympathy implies agreement and judgement.

Emotional Bank Accounts

Covey uses the term "emotional bank account" to describe the ever changing level of trust between two people. The very process of empathic listening is an Emotional Deposit - it fulfills a basic need of being understood, appreciated, affirmed. This is building up the ability, trust and good will to work together (interdependence).

Empathy is Risky and Hard - It's for True Pros

Risky because you really open up to be influenced. You put aside your own agenda and seek to understand.
Hard - it is easier to draw on "what worked for me".
It's the mark of professionals - A doctor (diagnoses before prescribing), A salesman (Solutions, not products).
We tend to evaluate, probe, advise and interpret from our frame of reference. 

To understand we need the combination of: 

• a desire to understand
• strength of character
• positive emotional bank account
• Emphatic Listening Skill

Steps to develop the skill:

1. Mimic content you hear, reflect. Show you heard and pay attention
2. Rephrase what you hear (apply thinking)
3. Reflect feeling ("you're feeling...")
4. Rephrase and reflect feeling - build trust to open up

Apply it whenever it gets emotional. Help the speaker reflect on his words, rephrase, change their mind..

...Then, seek to be Understood

Covey defines Maturity as the balance between courage and consideration. After applying consideration by truly listening, it's time to courageously communicate what you have to say. 
Ethos, Pathos and Logos are the building blocks of an effective presentation:

• Ethos: your credibility, emotional bank account
• Pathos: emotional alignment, empathy
• Logos: logic and reasoning

This means, aiming at the context of your audience, at their frame of reference. By doing this you might learn and change the content of your presentation (that was the "risk" when you listen - you might just learn something!)

And here is the long term benefit, and why you may want to apply this with your family: 
The more you understand someone - the more you appreciate them and experience meaningful connection.

Related reading

Nonviolent Communication by Marshall B. Rosenberg

McCarthy's core protocols: Investigate

Software AG at Agile India 2014

On January 2013 I had the great experience of sharing in Israel some of what we learned at Software AG during our ongoing road to Lean and Agile, and I know of a couple of other colleagues who presented at other conferences.

Last week, Bangalore hosted the Agile India 2014 conference. Four days packed with speakers from all over India, and many international speakers. This time, my colleague Harish Krishnaswamy was presenting a very different perspective of our story. You can find the slides here, or read the full experience report which is packed with information and inspiring data of the significant impact of the transformation. I recommend to people interested in large scale transformations - read the report. Harish did a great job collecting information and interviewing many people in different roles regarding the journey. I'm sure people of Software AG would find it interesting to read a story they played a role in from a different, more holistic perspective.

An impressive amount of four more Software AG employees gave lightning talks: Amit Deshpande, Heartin Jacob, Chandan Ravishankar and Ramya Gopalakrishnan.

Amit spoke of Scrumban, a combination of Scrum and Kanban which can be used in those circumstances where you have a mix of feature development and technical debt/customer issues. In particular customer issues or unplanned events that could be disruptive to the planned work in a sprint.

Heartin blogged on the topic of his talk: what success means in Agile and how Agile helps us to be successful, highlighting the strong bond linking technical and organizational success with the personal success of individual contributors. 

Chandan asked why are you following Agile? The key point is that following the practices becomes an empty shell without being a part of the transition, caring and having personal engagement with the work you do (aligned with Heartin's theme). Another is the point that agile practices are designed to keep you honest about what you can deliver on a sustainable pace, and encourage you to aim higher based on the current reality and your history.

Ramya talked of using WIP limits to reduce Context Switching, sharing the specific context and behaviors the team adopted to deal with complexity, reduce stress and maximize learning and collaboration. I'm not sure how common it is to do an exercise with the audience demonstrating context switching in a five minute lightning talk and still have time to say something - wow!

Such evidence strengthens my belief that the transformation we're going through at Software AG runs deep - many individuals align with it and contribute well beyond their job description for the success of the organization, for technical excellence and in support of their own growth.

Agile Practitioners 2014 Conference Impressions

I know Lior, Elad and Ilan, a.k.a. Practical Agile, for a while now. I had the opportunity to speak in the Agile users group they organize (and attends sessions) and also to speak on last year's conference. There were also workshops and other activities, including the unforgettable Coach Retreat Tel Aviv with Yves Hanoulle. 

Board Exhibition

This year's Agile Practitioners conference had 3 tracks to choose sessions from, other than the key notes. 

The venue was a good match to the needs. I liked the exhibition of team boards arranged by Amit Yedidia. I also liked the feedback green boxes and the feedback notes: they were small enough to make you give short comments, and it was phrased to get positive comments and things to improve.

Keynote by Jutta Eckstein

Jutta Eckstein gave the opening keynote, "Towards a learning organization". She started with her view on the origins of agile: Toyota, the SmallTalk community and Patterns (architecture and process) and identified a shift in application focus from smaller teams to larger and distributed organizations, and extending outside software development over time. 

Jutta Ecktein's key note

Different adoption strategies hold different risks. Specifically, top-down approaches tend to rely on certifications, which may ensure some knowledge but come short on developing skills, performance and the mindset of continuous learning. Think of a diving master who'd be allowed to guide before ever getting wet. A better option is to follow the famous Shu-Ha-Ri approach as coined by Cockburn.

What organizations need to understand going agile is that it is a cultural change. HR can support this change as a personal development initiative towards more personal responsibility. Performance evaluation and MBO plans will need to change to prefer team achievement over personal goals. Managers need to serve as role models for learning, for allowing failures and admitting their own mistakes.

See also: cool sketch of this talk by Angel Medinilla.

Project Retrospectives

Next I attended Naama Gafni Lifshitz who shared her insights about hosting Project Retrospectives. She had a bunch of very useful, practical tips and structure. Great stuff on how to prepare, who to open, gather input in groups, cluster it all (with pre-thought-of color coding!) and prioritize, investigate for root causes and potential solutions and how to wrap it all up. Look for the slides once they are public if you plan for such a retro to get the tips - and pitfalls to beware of.

Developing Great Scrum Masters

Angel Medinilla is about to brag

Angel Medinilla (@angel_m) gave a funny and energetic session, identifying the limited amount of guidance scrum masters have regarding their role and offering help with a few archetypes: the go-through-the-motions "Scrum Dude", the over protective "Scrum Mom", and "Yoda" the facilitator, true scrum master, who grows the team, teaches how to deal with conflict and delegates progressively (self organization is not a boolean attribute...). Next comes the hypothetical "Agile Nirvana", the scrum master who inspires agility by his/her very presence.

To be effective, the scrum master needs to be one step ahead of the team on this continuum - the delegation oriented Yoda will get blank stares from the beginner team who's used to the Dude. Get them a Mom.
To develop great scrum master, you'll need to acknowledge they need to combine technical understanding, human skills and agile knowledge. based on the current skills, invest in learning to get a balanced mix of capabilities.

Ready, Steady - Sprint!

Avi Naparstek, Shirly Harel Ronen and Dan Kuida hosted a card game, which was aimed to get the players familiar with various agile practices and which problems they can address. The short session wasn't enough to get the full set of rules across, so playing was somewhat chaotic - but at least some of the concepts came across nicely and the atmosphere was playful. The cards were beautifully designed and executed, and with more time I'm sure the game can come in as a fun and useful educational experience.
Here's a full report of it with many more details by Avi.

Uri Nativ - Stop Optimizing Start Simplifying

Uri's talk focused on efficiency vs. effectiveness, against the old-school management concept of maximizing utilization and "correct" assignment per expertise. Focus on results, on delivery, on velocity.
Another management pattern to avoid is making KPIs the goal. KPIs are useful indicators, but they must come with human judgement and feeling. Can't truly measure some things such as productivity or technical debt. Here are the slides.

Oren Ellenbogen - 5 leadership hacks for building great teams

Oren shared some insights and ideas he came up with after taking on a management role. I liked many of the ideas - applying a system of "code review" to management decisions, how to welcome new employees in a personal memorable way, how to recognize team members, how to embrace simplicity and how not to let HR have all the fun congratulating people for birthdays and such, taking out the personal connection. I loved that he called it "stop outsourcing your emotions".

Mike Vizdos - using scrum  and lean startup 

Angel did such a great job with the sketch I really have nothing to add: Another great sketch by Angel Medinilla.


As there were three tracks I know I missed some great talks, but that's life. Again, another great conference, and I've yet to write of the other events that came along with this. Well done, folks!
More on the twitter tag #APIL14

Upcoming Agile events to look forward to

I've been on a break from blogging since my daughter's birth, but here's a heads up to some events I'm looking forward to and expect to write about.

Agile Practitioners 2014 conference events this week:

1. 28-Jan-2014 - Workshop: Jutta Eckstein, on ‘Agile Software Development in a Large and Distributed Environment’
2. 29-Jan-2014 - the Agile Practitioners 2014 conference day - here's my post on it
3. 30-Jan-2014 - in the spirit of "Code Retreat" and "Coach Retreat", the first ever "Retrospective Retreat"!

Yet, it doesn't stop there! The week after, on February 3rd, Dave Snowden will be giving a talk "Complexity in human systems" at SAP labs.

Stay tuned :)

Habit 1 - Be Proactive

This is a part of my Introduction to Covey's 7 Habits series.

The first habit, the imperative "be proactive" is derived from the fact that Humans can think about thoughts. This self awareness, abstract level of reflection, empowers us so we may overcome some very strong powers that guide us by default.

Determinism

These forces are often considered to determine our life.

• Genetic determinism - grandma did it to me! no wonder I have such temper
• Psychic determinism - mommy did it to me! no wonder I have stage fright
• Environmental determinism - my boss / my spouse / the law / traffic...

Experiments with animals showed you can create stimulus-response relationships. This notion is often thought of as a system to influence human behavior with "carrots and sticks" (or MBOs).

We have a way out

Having self awareness, imagination, conscience and will - we can choose. We can always choose.

Viktor Frankl called that freedom to choose "response-ability". You could have Liberty, but without mastering Responsibility, the ability to choose your response - you do not have true Freedom.

Why is it called "Be Proactive?"

Proactive as opposed to Reactive. Being reactive means you let others drive your emotions and behaviors. Being proactive, you are driven by your own values. You take initiative and don't wait for someone to take care of you.

Reactive people often use a victimized language: "have to," "he makes me", "they won't", "it's just the way I am", "that's the way things are"

Circle of Concern  & Circle of Influence

Covey points out that each of us has a part of the world we are concerned about, and a part we can influence. Proactive people focus their energy in their circle of influence, and by doing that they increase their influence over time. Wasting energy on the part we're concerned about but can't influence is likely to be less effective and mostly filled with complaint, blame and negative energy, which in turn shrink the circle of influence with time.

The problems we encounter are either under our direct control (our own behavior), our indirect control (other people's behavior) or we might have no control over them (such as the past).
The solution to the problems over which we have any control lies with practicing the habits, while wholeheartedly accepting those outside our circle of influence. We might not be able to choose the reality, but we are able to choose our response and reaction to it.

Homework

Covey suggests some  things you can do to practice the first habit. Focus on being - when you complain about another you aren't influencing anything for the better. The only thing you control is your own behavior.

• Try applying the principles of being proactive (while trying to avoid being reactive) for 30 days and observe new outcomes
• Take a full day to listen to the language you and people around you use - tune to hear reactive phrases such as "if only", "I can't", "I have to", "they should"...
• Use your imagination to visualize a situation you typically behave in a reactive way, and imagine ways you could response proactively. Replay this new scenario to yourself and commit to choose this behavior in the next opportunity
• Choose a problem that frustrates you, and decide if it is in you direct control, indirect control or no control, and find the first step you can take in your circle of influence - and take it

Related reading

All I posted related to responsibility.

Introduction to Covey's 7 Habits of Highly Effective People

Last month I posted Sharpen the Saw, which points at links between Stephan Covey's book "The 7 Habits of Highly Effective People" and other ideas.


One comment triggered me to consider writing a series of more basic posts about each habit. I'll use this post as a cover post that links to the next ones as they come, so this one will be updated as I make progress.

Private Victory

The first 3 habits are in the realm of "private victory", growing from a dependent state, to an independent state. Become able to choose your actions, clarify your values and goals and plan and execute effectively towards those goals.

1. Be Proactive

How to beat the perceived determinism of our lives by choosing our responses.
See: Habit 1 - Be Proactive

2. Begin with the End in Mind

How to decide what you want, and lead yourself into the direction you choose.
See: Habit 2 - Begin with the End in Mind

3. Put First Things First

<coming soon>

Public Victory

The next 3 habits deal with going beyond what you can achieve independently. You can reach further by mastering interdependence, the ability to work with others towards shared goals.

4. Think Win-Win

<coming soon>

5. Seek First to Understand, Then to Be Understood

How to really listen, to content and emotion, to build deeper relationships and communicate your own ideas more effectively.
See: Habit 5 - Seek first to Understand, then to Be Understood

6. Synergize

<coming soon>

Continuous Improvement

7. Sharpen the Saw

<coming soon>

Agile Manifesto for Kids

This Sunday my daughter was born. While I'm busy with getting used to pink (after two boys) and until I blog again, I leave you with this. Feel free to download, print, connect the dots and try to identify who's who :)

If you didn't get it, you probably could spend more time here.

Christopher Avery's Leadership Gift Program

In some of my posts I referred to Avery's Responsibility Process. It's time to say some more, and let you know of a way to master it, if you're interested.

Background

I first encountered the model late 2009, when Software AG brought a consultant to help us learn and adopt lean and agile principles and methods. The funny thing, this guy talked about culture, mindset, emotions and psychology much more than process or technical skills or tools.
I had the opportunity to be part of a group that played a key role in learning and spreading the knowledge  in our R&D, across a good number of locations.

It would be ambitious to try to explain the Responsibility Process in a short blog post, when I usually take a three hour, experience rich, in-person workshop to give people a taste of it. What I can say, is it works for me. I use it on myself to choose my options in the face of problems, to keep myself engaged and caring about what I do and the people I work with. The people I work with know it, and it gives us a way to accept displays of blame, justifications, shame or obligation without taking it personally, helping each other out of those mindsets towards learning and resourceful action.

Christopher Avery teaches this model and more in his Leadership Gift Program, and the point of this post is to tell you about this opportunity. To be fair - I did not participate in it. First, because the timezone difference is demanding. But mostly because I was already underway on my own path: through the coaching I got at work, learning through audio recordings, teaching it over and over again, reading books and blogs, and attending Avery's workshop in Israel.

Opportunity

If you don't plan on taking such a path, here's another opportunity.

The Leadership Gift Program 2014 is a live, online, 17-week semester from November 2013 through February 2014 on which you learn this stuff and more with Christopher Avery. It's also a community of practitioners, supporting each other in mastering this stuff.

There's more to it. If you are interested, but not yet sure, here's what you can do next (until October 22nd):

• Go to www.ChristopherAvery.com/vip
• Enter your name, email and this VIP Code: LeanGuyVIP
• Take the time to join a free, content rich webinar, on either October 22 or 24 to hear more about it

What's with the VIP code?

If you use this code to register to the webinar and later choose to enroll to the program, you'll get a 100 USD rebate. There are different pricing options, the most common would typically cost 800 USD, so for you (being a reader of this blog) it will cost 700 USD.

Here are all my posts that have anything to do with Responsibility.

And here is the poster I translated to Hebrew:

Sharpen the Saw

Last week I had the opportunity to meet face to face with a group of colleagues from around the world, after a period of working together as a virtual team. I had the privilege to share some ideas I learned in the past few years. During my preparation I noticed some interesting overlaps and touch-points between these ideas. Here is a sketch these relationships between ideas, using Stephen Covey's 7 Habits wheel diagram as an underlying structure, while other books, concepts and disciplines as elaborate and enrich certain parts of it.

Covey's 7 Habits, and Friends

Here is the textual version:

1. Be Proactive

The first habit is all about learning to choose your reactions overcoming automatic patterns of behaviors based on emotional triggers. I think Christopher Avery did a great job modeling our typical emotional transitions when we deal with problems with his "Responsibility Process". 

2. Begin with the End in Mind

Covey's most morbid habit urges us to explicitly craft our own personal mission statement. We have one life, make it count. Well, having one life is sometimes used to justify some questionable actions (YOLO), but lets say the message is - make your life matter, don't waste it watching TV. Memento Mori rather than Carpe Diem.

Having read "Drive" by Dan Pink, it seems there's a virtuous cycle at play - tuning to a purpose in what you do, kindles your intrinsic motivation, making you more engaged and therefore likely to succeed.

3. Put First Things First

Covey's quadrants, categorizing tasks on dimensions of importance and urgency have been a corner-stone to any time management system. Notable in that area:

• Getting Things Done / David Allen
• Personal Kanban / Jim Benson & Tonianne DeMaria Barry
• The Pomodoro Technique  (ok, not so much about quadrants, but about time management...)

4. Think Win-Win + 5. Seek First to Understand, Then to Be Understood

Both relate to NonViolent Communication: seeking first to understand is all about emphatic listening, while thinking win-win could be thought of as aimed to address the needs of both parties assuming abundance rather than regard realty as a zero-sum-game (in which for me to win you'll just have to lose).

6. Synergize

A Hyper-Performing Team is a whole, being more that the sum-of-its-parts. To boost your team coaching skills, here are quite a few good sources of inspiration:

• Teamwork is an Individual Skill / Christopher Avery
• Collaboration Explained / Jean Tabaka
• The Core Protocols / Jim & Michele McCarthy
• The Human Side of Agile / Gil Broza
• Coaching Agile Teams / Lyssa Adkins

7. Sharpen the Saw 

This diagram and blog post is a result and a part of an ongoing, continuous search for new ideas and deeper understanding.




I suppose this may be over simplistic, and based only on some of the things I personally encountered so far. How would you improve it? What are you missing here?

Update: I started A post series introducing Covey's 7 Habits.
  

Image Formats: a Quick Guide for the Perplexed

From time to time I find myself explaining the differences between some of the common image formats, and when you'd better use each. I thought it would be useful to post about it, especially since I'm sure I'm going to learn something new in the process.

Raster vs Vector

Raster and Vector images: zoom in

Most commonly used are Raster image formats, such as bitmap, jpeg, gif and png. Raster means, there are pixels arranged in a grid which makes sense because most if not all display devices are eventually made of grids of pixels. However, Vector formats keep the image represented as geometric shapes, rendering to pixels only when actually displaying. This way, there's no low resolution problems. Think of flash graphics, or PowerPoint, or PDF (when not made of a scanned document) - you can zoom in as much as you want, and the curves remain sharp. These formats are often used for print, by designers, CAD tools, games, etc.

So lets focus on the raster image formats.

Bitmap (.bmp)

Bitmap is as simple as they come - uncompressed. The data for each pixel is stored in a pixel array, according to the defined image color depth (from 1-bit per pixel which is just black and white to 32-bit which supports over 4 billion colors, and even transparency information). Being that simple, almost anything can display it, so that's the up side. File size is another matter - bitmaps can get huge. Ever got a 5MB email just because someone dumped a screenshot in it?
Usually bitmaps don't contain transparency data, and even when they do, most applications don't support displaying it properly - so for most practical means, it's fair to say bitmaps don't support transparency.

Graphic Interchange Format (.gif)

GIFs are limited to 256 colors (or 255 + transparent pixels). The image data is compressed in a loss-less algorithm - meaning the quality of the image isn't damaged due to the compression. If the original image contained more colors, the first conversion to GIF will reduce the quality, of course (this effect is called "posterization").
These attributes make GIF a light weight and widely supported image type that works well for simple images, logos, diagrams, cartoon style drawings, etc - but not for photos or graphics rich with gradients.
Oh, and GIF can be animated, too.

Portable Network Graphics (.png)

GIF was patent protected, and legal disputes triggered the development of PNG as an alternative. And a good thing too - it supports rich color, and a full alpha channel - and typically compress even better than GIFs unless the image is very small. Wait... what's an alpha channel? Well, remember how GIF can have transparent pixels? In PNG, each pixel can have any level of transparency, which is great for combining images. However, PNG doesn't support animation.
Note that while it can support photos, it's compression works best for images with large blocks of solid color, similar to GIF.

JPEG (.jpg, .jpeg)

Designed for photos, this is the default standard file type most digital cameras produce. Photos are assumed to have some unstructured noise in them, and typically low contrast color transitions. These attributes allow using compression which is lossy - when you save an image as a JPEG, some noise may be added to it. The more noise you are willing to take, the stronger compression you can have.
The compression uses the same math that's in MP3 - discrete cosine transform (DCT), which is similar to Fourier transform. In a nutshell, the image is broken to 8x8 pixel squares, and each is represented as a combination of frequencies (or cosines). The amount of noise can be controlled for trade-offs of size versus quality.  
No transparency or animation.

The Cheat Sheet

Format	Extension	Best used for...	Compression	Transparency	Animation
Bitmap	.bmp	Anything if you don't care about size	none	none	none
GIF	.gif	Simple graphics, logo, icon, silly cats, limited colors	lossless	boolean	yes!
PNG	.png	Most graphics	lossless	full	none
JPEG	.jpg	Photos	lossy (noisy)	none	none

Useful Links

To learn more, here's a good start: Image file formats (wikipedia)
Cool free service for image size optimization: kraken.io/web-interface

Collaborative office space

In preparation for some changes in our office layout, I was interested to do a little research on various ideas on the topic.

Caves and Common

In Agile Software Development (2nd edition) chapter 3 (and 3.1), Alistair Cockburn describes a possible office layout - with the team room (programming room) having a central cluster of tables where pairs sit facing the center, with some more private areas on the side of the room. This is known as "Caves and Common". There's research backing this up in the book, rephrasing the Allen Curve (communication exponentially drops with distance) as the "school bus rule".
That's the typical agile team room (blogged by Martin Fowler).
This is sometimes also called a War Room.
Another blog that argues for this setup with lots of references: The Ultimate Software Development Office Layout

Inward facing U-Shape

Another setup. Well, it probably goes with an open space for multiple teams. Cool idea of joining a whiteboard and special projector. Each team member can share their screens on the team board with a single button press.

U-Pod

Martin Fowler blogged about another option of a U shaped space, where people face out side. While it is easier to roll over towards each other, it is harder to find a place for a team board. And avoid the corners, bad for pairing.

Here's a recommendation by someone who tried it.

This is sometimes referred to as "The Bullpen".

Half Height Cubicles

Richard Cheng recommends half height cubicles. His slides show some additional options, considerations and aspects (I think he's missing the point of avoiding the corner made by Martin Fowler). In context of his slideshare, I think this is evangelized as an improvement to the previous single person cubicles. 

The Bionic Office

Right... Cool, perfect for focus and personal effectiveness, but totally optimized for working alone, inhibiting communication and collaboration.

After the first wow effect, agile teams optimize for team results rather than individual performance.

Overviews

Dafydd Rees (the programmer) shares his experience with different arrangements covering more or less similar setups.

InfoQ cites Mike Cohn on Workspaces for Effective Agility - not so much about the physical layout, but some aspects to take care of.

My Conclusion

There are many variants, and some would be more effective than others depending on context, individuals, team size, company culture and office constraints. You'd want to consider:

• Ease of communication
• Ability to focus (reduce distractions)
• Team ownership of the space (use of information radiators)
• Adaptability when needs change

Oh, and don't sit in an L shaped corner if you're ever going to pair...

What's your experience with various office setups?  

Update:
A short clip case studying the Stanford design school, and their concept of the impact of the work environment on learning, engagement and teamwork.

Can you copy a culture? The NUMMI story

In 2010 I came across a brilliant radio show of This American Life - episode 403: NUMMI.
It tells a story that's taught in business schools, of a joint venture by General Motors and Toyota - in 1984 these competitors decided to build cars together, each for their own reasons. NUMMI is the name of the factory, it stands for "New United Motor Manufacturing Inc".



Act one tells the miraculous story of this GM factory in California - it was considered to have the worst work force, always striking, struggling against management, with no work discipline what-so-ever: drinking on the job, drugs, gambling. Then, Toyota stepped in and transformed this plant into a Japanese style plant, using the Toyota Production System (TPS) principles. The real miracle is that it worked - and that 85% of the work force was the same. This a truly inspiring story of human potential and how systems can be designed to bring the best or worst of of people.

Act two is a different story. GM was for decades losing ground to Toyota. It had every reason to want to learn whatever they could from NUMMI and improve their quality across their other plants. This didn't happen - at least not fast enough. In 2010 GM went bankrupt. This part reveals some of the reasons and dynamics that led to the tragic outcome.

I recommend investing an hour to listen to it. Act one tells you how to get it right, and it is really emotionally moving - the interviews with employees who went through the transition reveal NUMMI deeply changed the lives of many. It also describes some of the key aspects of the TPS and how it was successfully brought to the US.  Act two  is a handbook for nearly everything that can go wrong when you try to change an enterprise.

What I like about this radio show is that it demonstrates so well that the Toyota Production System is not a "business process", or "best practice" you can see and replicate. It is a culture, with it's own values. It is not something you can just perform, it is rather something you can choose to become.

Agile transformation often suffer from similar difficulties - you can follow the rituals, but if you don't get the underlying values and mindset, you just end up creating "cargo cults", or simply resistance.


I'd like to thank Elliot Holar who shared this episode with me soon after it was aired - aside from this specific episode, I became quite a fan of This American Life. They rock. Thanks, e.