Skip to content


Strategy Deployment, the X-Matrix and Kanban Thinking

AvailAgility - Karl Scotland - Tue, 11/25/2014 - 10:00
Strategy Deployemnt

Kanban Systems are an enabler of evolutionary change. And so is Strategy Deployment. Strategy can be defined as how you will make a positive impact, and this implies change. As the saying goes, “hope is not a strategy”, and neither is doing nothing. Deploying that strategy, as opposed to defining and imposing a tactical plan, enables the evolution of the tactics by the people implementing them.

I have found that putting Strategy Deployment in place is my preferred approach to starting off any change initiative, and that as suggested above, there is a strong synergy with a kanban-based approach. (This is not surprising, given the roots of both in Toyota and Lean). In particular, I have been using a format known as the X-Matrix to setup Strategy Deployment.

The X-Matrix

The X-Matrix is a cornerstone of Strategy Deployment. It is an A3 format that provides a concise and portable shared understanding of how strategy is aligned to the deployed tactical initiatives, alongside leading indicators of progress and anticipated end results. I learned about the X-Matrix from the book “Hoshin Kanri for the Lean Enterprise” by Thomas L. Jackson, and I have previously blogged about how we used the approach at Rally.

CD Form 1-2_A3-X X-matrix

The X-Matrix has 5 primary sections, all of which are connected. At the bottom, below the X, are the results that we hope to achieve. To the left of the X are the key strategies that will get us to those results, and to the immediate right of the X are the measures of improvement that indicate how well we are doing. (Note that this is labelled process as it refers to process improvements). At the top, above the X, are the tactics that we will use to implement the strategy. Finally, on the far right are the teams that will be involved in the work. To link these together, the corners of the X-Matrix are used to show the strength of correlation or contribution between the different elements.

Thus it becomes easy to visualise and explore how a strategy, or a measure, correlates to achieving results. Similarly, it is easy to see and discuss how a tactic will correlate to achieving a strategy, or how it will contribute to moving the needle on a measure. And it is clear who is accountable or involved in each tactic. Having all this on a single page helps creating clarity and alignment on the why, how, what and who of the work.

Kanban Thinking

This works well because it wraps all the elements of Kanban Thinking nicely. The results are equivalent to Impacts, the process improvement measures are ways to Sense capability, the strategies can be derived from exploring various Interventions and the tactics are the experiments created to Search the landscape. (Note: While all the examples I have seen have financial results, focussing on value based impacts, there is no reason why flow and potential based impacts could not be forecast with alternative results).

What I really like about Strategy Deployment, and the way Jackson describes it in his book, is that it is a form of nested experimentation. From an organisations long-term vision, through its strategy, to tactics and day to day operations and action, each level is a hypothesis of increasing granularity. As each experiment is run, the feedback and learning is used by the outer levels to  steer and adjust direction. Thus a learning organisation is created as the learning is passed around the organisation in a process known as ‘catchball’, and within this context, Kanban Thinking (and the Kanban Method) provides a synergistic means to running experiments and creating learning.

Do you know what results your organisation are aiming for? Do you know the strategies being used and how they should lead to the results? Do you know what improvement measures should indicate progress towards the results? Do you know how your tactical work implements the strategy and which indicators it should improve? Are all these elements treated as hypothesis and experiments to create feedback and learning with which to steer and adjust?

If you’d like help answering these questions, using the X-Matrix, let me know!

Categories: Blogs

Quick Retrospective

Scrum 4 You - Tue, 11/25/2014 - 08:25

The Retrospective meeting is one of the six meetings in Scrum. The main purpose of this meeting is to get an overview of the last sprint. The Development Team has the opportunity to reflect on the process and to identify the advantages and disadvantages of the current sprint and its work procedures.

I would like to introduce you to four different types of a quick retrospective, especially focused on teams who are participating in this type of meeting for the first time. It is common that team members are not really willing to open up and express their feelings, problems, experiences at the first couple of times. Therefore, only the Scrum-Team (DevTeam, SM, PO) is allowed in that meeting, others can only join with the DevTeam’s permission. It is a learning process and the team has to adapt to this new environment of openness. However, every team is more than welcome to use these methods regularly and for other intentions, eg. a short retrospective after every meeting to analyse how helpful and productive it was. A retrospective after a sprint review would give an insight on how stakeholders experienced the meeting.

Rocket Retrospective
  • Outcome: Quick self-awareness
  • Timebox: 15 minutes
  • Material: Marker, post-its, paper cards

It is important that you limit the time to your time box and do not extend any parts of the meeting.
The first step is called “Appreciation” and it should not take longer than five minutes because your DevTeam members just have to write down all the positive changes that had an impact on them and their project.

The second step is referred to “Collection of Information”. Every team member gets a card and a pen and he/she has to write down something that should be implemented or something that should be eliminated. Additionally, it is necessary that the person explains what exactly the problem is, why it is a problem and what are the benefits if it is implemented/eliminated. The members have to finish this task within five minutes. Afterwards, all cards are put upside down on a table, so nobody can see what is written on them. Once all cards are on the table the ScrumMaster collects and shuffles the cards.

The last step is termed “Making a Decision”. Each team member has to pick up one card of the table and take “ownership” of it. Then he/she has to write at least one proposal of action on the back of the note. It could be something as simple as writing an email or meet with another team member for 10 minutes two times a week, etc. Once everybody has finished this task, they present their card one by one with the issues and proposed follow-up actions. If some cards are similar those team members get together and put their solutions together on the back.

The ScrumMaster should keep the cards and put them on a whiteboard for everybody to see. The ScrumMaster has to bring the cards at the next retrospective for the participants to give appreciation on them.

Gifts & Hooks
  • Outcome: Participants will discover their colleagues’ strengths and expectations
  • Timebox: 15-30 minutes
  • Material: Pen and paper

The participants have to write down their strengths on paper within 10 minutes. Their strengths are called gifts because they have to list how they could contribute to the project to make it successful. Afterwards every participant has to list every ‘hook’, which are all the things that stand in their way to work more efficiently. At the end everybody shortly presents their list and then the discussion can start on how to remove those hooks preferably.

Genie in a Bottle
  • Outcome: Intuition for urgent problems
  • Timebox: 15-20 minutes
  • Material: Flip chart and pens

The team tracked down an ancient bottle. A genie appeared when they opened it. The genie told the team that he/she will grant them three wishes regarding changes at their workplace. And the genie will fulfil them. Now the team splits up into groups of three and list their three wishes on a flip chart and hangs it on the wall for everyone to see. Every team explains why they think those three wishes are the most important ones . The ScrumMaster asks the participants what needs to change for the wishes to become true. Now the SM has a list of the most urgent impediments he/she has to take care of. The charts will be presented at the next retrospective again to see if anything has changed in the meantime.

Hot-air Balloon
  • Outcome: Identify things that influence the work flow
  • Timebox: 15 minutes
  • Material: Pens, post-its, whiteboard

The ScrumMaster should draw a hot-air balloon on the whiteboard and then ask the participants to write notes and stick them on the following areas: fire, hot air, and forces pulling down. The team has to identify what helps them to go higher and what pushes the project forward by placing those post-its on fire and hot air. Meanwhile, the things that hinders them to work productively are the forces pulling them down. This should not take more than five minutes. Then the team has 10 minutes left to discuss the issues.


Categories: Blogs

New CSG Case Study: Lean, SAFe and DevOps in a Complex Legacy Environment

Agile Product Owner - Mon, 11/24/2014 - 21:10

A short while back, I blogged about Scott Prugh’s recent presentation at DevOps Enterprise Summit 2014, where he described the way CSG has been able to address some of the complex challenges in accelerating more frequent delivery in a large, complex, multi-platform legacy environment.

Case Study CSG InternationalThat triggered us to provide a little more context about our work together at CSG, where we have a long and productive relationship that goes back five years or so.  It continues today. And as readers know, SAFe was invented in the field, and CSG is one of those places. (I think it was Taichi Ohno who said “no useful improvement was ever invented at a desk” – but I seem to have lost the source for that quote.)

In this case study, you’ll see a bit of that history, and you’ll also link to Scott’s recent presentation. evidence of how principles like cadence and synchronization, cross functional teams, visualizing work, backlog management, reducing batch size, and synchronized release planning (just to name a few) can increase the quality, throughput and delivery of large scale software in a seriously complex, legacy environment. Exciting stuff. Check out the Case Study here.


Special note: I also felt compelled to use this opportunity to again mourn the loss of our colleague, Mauricio Zamora. Mauricio Gaston Zamora died unexpectedly on Thanksgiving Day at the young age of 42, while running with his wife and son in Meyer Park, Houston. This post is being published on the third anniversary of his untimely passing. Rest in peace Mo. Your legacy lives on in SAFe.


Categories: Blogs

Heuristics for Becoming a Learning Organisation at Spark the Change

AvailAgility - Karl Scotland - Mon, 11/24/2014 - 20:22

InfoQ have just published the talk I gave at this year’s Spark the Change conference on “Heuristics for Becoming a Learning Organisation“. This was the first time I introduced the Kanban Canvas, and gives some background to the questions it asks.

Please follow the link to watch, as I can’t embed it here.

Categories: Blogs

Scaling Continuous Delivery

TV Agile - Mon, 11/24/2014 - 19:26
This talk covers how we have dealt with bottlenecks, technical and organizational, while scaling our Continuous Delivery process. Three years ago we started building our continuous delivery process. We were in desperate need of continuous regression testing. Our delivery platform was growing more so was the number of stakeholders putting requirements on the platform. So […]
Categories: Blogs

News update 2014/11 – Here Be Dragons – Scaling Agile - Peter Hundermark - Mon, 11/24/2014 - 16:49

Serpents and DragonsPeter Hundermark has shared the slides of his presentation, “Here Be Dragons – Scaling Agile“, from the global Scrum Gathering in Berlin and the regional Scrum Gathering in Cape Town.

The presentation focuses on the structural and process dimension of scaling agility. Peter describes 3 “laws” of scaling and sets out 10 patterns that he has found helpful over the years as a consultant and coach.

Interesting Links Interesting Links Momentum BTS Momentum BTS have embarked on a journey of learning and innovation by introducing Kanban as a way of managing their work. They have posted a short video on YouTube illustrating the impact these changes have had on their teams. Scrum Sense has had the privilege of being a part of this journey.


InfoQ have also published an article on Momentum’s adoption of Kanban. Discover the reasoning behind their journey and how they went about implementing the changes.


Scrum Gathering South Africa Karen & Sam of Growing Agile, interviewed attendees of the October 2014 Scrum Gathering in Cape Town and have created a very cool video of which sessions they enjoyed most and what they learnt.



Upcoming Courses


Certified Scrum Master (JHB)
01-02 Dec 2014 – Fully booked!
FNB Conference & Learning Centre, Sandton


Certified Scrum Master (CPT)
26-27 Jan 2015
Steenberg Hotel, Cape Town


Certified Scrum Product Owner (CPT)
23-24 Feb 2015
Steenberg Hotel, Cape Town


Certified Scrum Master (JHB)
10-11 Mar 2015
FNB Conference & Learning Centre, Sandton


Course Schedule and Book Online


The post News update 2014/11 – Here Be Dragons – Scaling Agile appeared first on ScrumSense.

Categories: Blogs

Coal in your bug tracking stocking this Christmas?

Agile Complexification Inverter - Mon, 11/24/2014 - 16:43
What is your plan for being a better developer next year?  What's the technique that will repay your efforts many fold?  Testing - automated test to be specific.  There are all types of automated testing.  The agile mind set thinks of testing first, not in a reactive manner, but as a preventative and design effort.

For three years, The Container Store has been using application performance management (APM) technology from AppDynamics to locate bugs in the website, target them immediately and fix them.

Sometimes there's a slowdown in a particular region. Other times it's from a certain database and often from a single line of code. Just this year, the Container Store upped its contract with AppDynamics, buying more software so the company can test new features before deploying them and minimize the number of live fixes necessary.

"We said we want to be more proactive instead of reactive," said A.J. Azzarello, a quality assurance engineer at The Container Store in Dallas. "We can catch errors and slow response times in test prior to production so they never impact our customers."From CNBC's article: Don't let software bugs ruin Christmas by Ari Levy

Categories: Blogs

A Tech Lead Paradox: Delivering vs Learning - Mon, 11/24/2014 - 14:49

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Delivering versus Learning.

The case for delivering

In the commercial of software development, there will always be pressure to deliver software that satisfy user needs. Without paying customers, companies cannot pay their employees. The more software meets user needs, the more a company earns, and the more the company can invest in itself.

Business people will always be asking for more software changes as there is no way of knowing if certain features really do meet user needs. Business people do not understand (and cannot be expected to fully understand) what technical infrastructure is needed to deliver features faster or more effectively. As such, they will always put pressure on to deliver software faster.

From a purely money-making point of view, it is easy to interpret delivering software as the way of generating more earnings.

The case for learning

Software is inherently complex. Technology constantly changes. The problem domain shifts as competitors release new offerings and customer needs change in response and evolve through constant usage. People, who have certain skills, leave a company and new people, who have different skills, join. Finding the right balance of skills to match the current set of problems is a constant challenge.

From a technologist’s point of view, learning about different technologies can help solve problems better. Learning about completely different technologies opens up new opportunities that may lead to new product offerings. But learning takes time.

The conflict

For developers to do their job most effectively, they need time to learn new technologies, and to improve their own skills. At the same time, if they spend too much time learning, they cannot deliver enough to help a company to reach their goals, and the company may not earn enough money to compensate their employees and in turn, developers.

Encouraging learning at the cost of delivering also potentially leads to technology for technology’s sake – where developers use technology to deliver something. But what they deliver may not solve user needs, and the whole company suffers as a result.

What does a Tech Lead do?

A Tech Lead needs to keep a constant balance between finding time to learn, and delivering the right thing effectively. It will often be easier for a Tech Lead to succumb to the pressure of delivering over learning. Below is advice for how you can keep a better balance between the two.

Champion for some time to learn

Google made famous their 20% time for developers. Although not consistently implemented across the entire organisation, the idea has been adopted by several other companies to give developers some creative freedom. 20% is not the only way. Hack days, like Atlassian’s ShipIt days (renamed from FedEx days) also set aside some explicit, focused time to allow developers to learn and play.

Champion learning that addresses user needs

Internally run Hack Days encourage developers to unleash their own ideas on user needs, where they get to apply their own creativity, and often learn something in the process. They often get to play with technologies and tools they do not use during their normal week, but the outcome is often focused on a “user need” basis, with more business investment (i.e. time) going towards a solution that makes business sense – and not just technology for the sake of technology.

Capture lessons learned

In large development teams, the same lesson could be learned by different people at different times. This often means duplicated effort that could have been spent learning different or new things. A Tech Lead can encourage team members to share what they have learned with other team members to spread the lessons.

Some possibilities I have experienced include:

  • Running regular learning “show-and-tell” sessions – Where team members run a series of lightning talks or code walkthroughs around problems recently encountered and how they went about solving it.
  • Update a FAQ page on a wiki – Allows team members to share “how to do common tasks” that are applicable in their own environment.
  • Share bookmark lists – Teams create a list of links that interesting reads based on problems they have encountered.
Encourage co-teaching and co-learning

A Tech Lead can demonstrate their support for a learning environment but encouraging everyone to be a student and a teacher at the same time. Most team members will have different interests and strengths, and a Tech Lead can encourage members to share what they have. Encouraging team members to run brown bag sessions on topics that enthuse them encourage an atmosphere of sharing.

Weekly reading list

I know of a few Tech Leads who send a weekly email with interesting reading links to a wide variety of technology-related topics. Although they do not expect everyone to read every link, each one is hopeful that one of those links will be read by someone on their team.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Categories: Blogs

Five Tips to Hiring a Generalizing Specialist

Johanna Rothman - Mon, 11/24/2014 - 14:19

We talk a lot in agile about generalizing specialists. Scott Ambler has a terrific essay on what a generalizing specialist is:

  • Has one or more technical specialties…
  • Has at least a general knowledge of software development.
  • Has at least a general knowledge of the business domain in which they work.
  • Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas

(From Scott Ambler’s essay,

How do you hire one of these mythical people?

First, they are not mythical. They are real. Second, you do a job analysis, just as you would for any job. Third, you would look at how they have acquired skills throughout their careers.

What does this mean for the hiring manager and/or recruiter?

  1. If you search on keywords only, you will miss these people. They may not have all the keywords you want on a resume. That’s because they are generalizing specialists. You have to write a job description to entice these people to an opportunity.
  2. If you say things such as, “You will have worked at a place like <insert name of your favorite company here>” you may well miss great people. You are assuming a particular class of people. You have to change your assumptions about work history, school history, any kind of history. Again, the job description or ad has to be about an opportunity where people can learn and grow.
  3. You have to look at how they have learned in their resume.
  4. You have to look at their technical leadership roles. Yes, they will show you technical leadership in their list of accomplishments. They will have made things better in any number of dimensions.
  5. You need to look at the non-technical skills, such as facilitation, collaboration, coaching, initiative, taking small steps to make progress, all the things I mentioned in Hiring for an Agile Team: Making Tradeoffs.

Remember, you want generalizing specialists. True specialists introduce a cost of delay into your projects. They end up with a queue of work and they introduce a delay, or they multitask.

Categories: Blogs

Der reflektierte Umgang mit sich selbst: Führung und Grundhaltung

Scrum 4 You - Mon, 11/24/2014 - 08:59

Wenn ich an meine langjährige Führungspraxis denke, nehme ich eine komplexen Prozess wahr, in dem vor allem eines immer wieder auf dem Prüfstand gestellt wurde: meine Haltung zur Profession Führung, als Führungskraft und zu den Menschen die ich führen durfte. Wie Menschen Führung – ob disziplinarisch oder lateral – ausüben, hängt in hohem Maß von ihrer (unbewussten und bewussten) Grundhaltung, von ihrer Rollenidentität ab. Das Führen von Menschen ist eindeutig und zuallererst ein Haltungsthema. Boris Gloger meint dazu in unserem gemeinsamen Buch “Selbstorganisation braucht Führung”: “Der erste entscheidende Schritt dazu ist: Vergessen wir alles, was wir aus Büchern, Vorträgen, Seminaren und von unseren eigenen Vorbildern über Führung zu wissen meinen! Damit meine ich auch dieses Buch! Es soll anregen, kann aber Ihr eigenes Denken und Ihre eigenen Schlussfolgerungen nicht ersetzen. Hinterfragen Sie einfach alles noch einmal, fangen Sie wieder von vorne an. Dieser Schritt ist entscheidend: Sie selbst sollten für sich ein neues Modell von Führung erfinden.“ Und damit eine ganz spezifische, individuelle Haltung entwickeln.

Immer wieder werde ich in Führungstrainings von skeptischen Teilnehmern gefragt, ob sie hier stromlinienförmig optimiert werden sollen. Die Antwort kann nur lauten: auf keinen Fall. Es geht nicht ums Klonen von standardisierten Führungsrobotern, sondern es geht um Anstöße für die individuelle (Selbst-) Reflexion, um die eigene Entscheidung, was in der Führungsrolle individuell “passt” und wie sie funktional und positiv interpretiert und ausgefüllt werden kann. Und es geht um das Andocken an die bisherigen subjektiven Erfahrungen zum Thema Führung. Denn jeder Mensch hat eine Vielzahl von Situationen er- und durchlebt, in denen er geführt wurde, in denen er Führung beobachtet und eingeordnet hat und die ihn heute mehr oder weniger stark prägen.

Die Rollenidentität als Führungskraft, und damit eine spezifische individuelle Grundhaltung, entwickelt sich durch komplexe Erfahrungen im Sinne von unbewussten und bewussten Lern- und Erfahrungsmustern. Unbewusst wirkende Überzeugungen und vorgelebte Werte aus Kindheit und Jugend, die wir von unseren Eltern oder späteren Vorbildern übernommen haben, beeinflussen uns und unsere Wertvorstellungen. Man muss lernen, sich dieser einflussreichen Überzeugungen und deren Auswirkungen auf das eigene Führungsverhalten bewusst zu werden, Position zu beziehen und bei Bedarf Veränderungen einzuleiten. Drei Positionen sind dabei wesentlich.

  • Die innere Haltung dem eigenen Ich gegenüber
    „Wofür stehe ich? Was macht mich als Mensch aus? Was motiviert mich? Lebe ich diese Dinge in einer wertschätzenden Haltung? Und wie bringe ich sie in Bezug zur Führungsrolle?“ Diese oder ähnliche Fragen stellen wir uns selten bewusst. Dabei sind sie absolut zentral. Sie sind die Grundlage unserer Handlungen und unserer Kommunikation. Und die Antworten auf diese Fragen zeigen sich in jeder Begegnung mit anderen Menschen, in jedem Gespräch. Und das selbst dann, wenn man nie über die eigene innere Haltung nachgedacht hat. Ein Blick auf die Meta-Ebene ist daher hilfreich: Es liegt viel Potenzial darin, sich mit dem eigenen inneren Antrieb, mit dem Kern dessen, was mich als Person ausmacht, zu beschäftigen. Um diese Entdeckungsreise zum eigenen Wesenskern anzutreten, ist es unerlässlich, in Ruhe nach innen zu hören und zu spüren und seine biographischen “Daten” Revue passieren zu lassen.
  • Die innere Haltung den Mitmenschen (Mitarbeitern) gegenüber
    Hier geht es um das grundsätzliche Menschenbild. Werden die Menschen als solche in ihrer primären Existenz eher positiv oder negativ gesehen, als vertrauenswürdig oder eher als unlauter, als fleißig oder eher faul, als Partner oder Konkurrenten usw. Führungskräfte, deren Hauptwerkzeug die Kommunikation ist, sollten sich daher im Bezug zu ihren Gegenübern auch situativ immer wieder – besonders aber in wichtigen Situationen – bewusst reflektieren.
  • Passung von Führungsrolle und Persönlichkeit 

    Passt die innere Haltung nicht zur Führungsverantwortung, dann entsteht ein Konflikt. Wer mit Worten für etwas argumentiert, das der eigenen inneren Haltung widerspricht, wird vom anderen intuitiv als unecht empfunden. Dieses inkongruente Verhalten sorgt für unbefriedigende Ergebnisse und lässt auch die Führungskraft auf Dauer unzufrieden zurück. Das Wort Persönlichkeit kommt von „personare“ und bedeutet „durchtönen“. Die Frage ist, wie gelingt es, die eigene Persönlichkeit stimmig in der Führungsrolle durchtönen zu lassen und gleichzeitig die Rollenklarheit zu behalten? Worüber muss ich intensiv nachdenken, was ist kongruent, wo muss ich mich anpassen oder entwickeln? Besonders laterale Führungskräfte brauchen oft Zeit und intensive Reflexion, um eine adäquate Position zu finden. Natürlich trifft die individuelle Interpretation der Führungsrolle immer auch auf die Führungskultur des Unternehmens und damit auf spezifische, mehr oder weniger transparente Erwartungen an die Führungshaltung von außen. Dies ist zu berücksichtigen. Unternehmen müssen daher grundsätzliche Anforderungen an die Führungshaltung definieren, die aber Raum für individuelle Gestaltung lassen.

Der erste Schritt allerdings ist es, sich über die tiefsten subjektiven Bezüge zur Führung klar zu werden. Finde ich Führung grundsätzlich notwendig, funktional und positiv? Oder habe ich meine Probleme mit dieser Form menschlicher Interaktion, vor allem Arbeitskontext? Lehne ich Führung eher ab und sehe sie sehr kritisch? Der Selbstreflexionsbogen Führung geht also nicht auf die konkreten Elemente der Führungshaltung ein, sondern soll helfen, die grundlegendsten Erfahrungen und Bezüge zur Führung transparenter und bewusster zu machen. Er fragt nach der elementaren Haltung und geht von der Prämisse aus: Nur wer gerne führt, führt wirklich gut!

Sollten Sie in der Skalenfrage das Kreuz bei 7 und mehr gemacht haben, sind Ihre Voraussetzungen für eine Führungsrolle sehr gut. Sie können einzelne Haltungselemente prüfen und den Fokus auf gut erlernbare Führungskompetenzen legen. Setzen Sie Ihr Kreuz bei 5 und darunter, empfiehlt es sich grundlegend, über Ihre Haltung zur Führung nachzudenken. Überlegen Sie, wo Blockierungen liegen könnten und was Sie bräuchten, um einen grundlegend positiveren Bezug zu entwickeln. Sprechen und reflektieren Sie mit Kollegen, Freunden oder einem kompetenten Coach. Und vielleicht gibt es ja auch Alternativen zu einer Führungsposition, um sich beruflich zu verwirklichen.

Categories: Blogs

R: dplyr – “Variables not shown”

Mark Needham - Sun, 11/23/2014 - 03:02

I recently ran into a problem where the result of applying some operations to a data frame wasn’t being output the way I wanted.

I started with this data frame:

words = function(numberOfWords, lengthOfWord) {
  w = c(1:numberOfWords)  
  for(i in 1:numberOfWords) {
    w[i] = paste(sample(letters, lengthOfWord, replace=TRUE), collapse = "")
numberOfRows = 100
df = data.frame(a = sample (1:numberOfRows, 10, replace = TRUE),
                b = sample (1:numberOfRows, 10, replace = TRUE),
                name = words(numberOfRows, 10))

I wanted to group the data frame by a and b and output a comma separated list of the associated names. I started with this:

> df %>% 
    group_by(a,b) %>%
    summarise(n = n(), words = paste(name, collapse = ",")) %>%
    arrange(desc(n)) %>%
Source: local data frame [5 x 4]
Groups: a
   a  b  n
1 19 90 10
2 24 36 10
3 29 20 10
4 29 80 10
5 62 54 10
Variables not shown: words (chr)

Unfortunately the words column has been excluded and I came across this Stack Overflow post which suggested that the print.tbl_df function was the one responsible for filtering columns.

Browsing the docs I found a couple of ways to overwrite this behaviour:

> df %>% 
    group_by(a,b) %>%
    summarise(n = n(), words = paste(name, collapse = ",")) %>%
    arrange(desc(n)) %>%
    head(5) %>%
    print(width = Inf)


> options(dplyr.width = Inf)
> df %>% 
    group_by(a,b) %>%
    summarise(n = n(), words = paste(name, collapse = ",")) %>%
    arrange(desc(n)) %>%

And now we see this output instead:

Source: local data frame [5 x 4]
Groups: a
   a  b  n                                                                                                         words
1 19 90 10 dfhtcgymxt,zpemxbpnri,rfmkksuavp,jxaarxzdzd,peydpxjizc,trdzchaxiy,arthnxbaeg,kjbpdvvghm,kpvsddlsua,xmysfcynxw
2 24 36 10 wtokzdfecx,eprsvpsdcp,kzgxtwnqli,jbyuicevrn,klriuenjzu,qzgtmkljoy,bonbhmqfaz,uauoybprrl,rzummfbkbx,icyeorwzxl
3 29 20 10 ebubytlosp,vtligdgvqw,ejlqonhuit,jwidjvtark,kmdzcalblg,qzrlewxcsr,eckfgjnkys,vfdaeqbfqi,rumblliqmn,fvezcdfiaz
4 29 80 10 wputpwgayx,lpawiyhzuh,ufykwguynu,nyqnwjallh,abaxicpixl,uirudflazn,wyynsikwcl,usescualww,bkvsowfaab,gfhyifzepx
5 62 54 10 beuegfzssp,gfmegjtrys,wkubhvnkkk,rkhgprxttb,cwsrzulnpo,hzkvjbiywc,gbmiupnlbw,gffovxwtok,uxadfrjvdn,aojjfhxygs

Much better!

Categories: Blogs

Make Stories Small When You Have "Wicked" Problems

Johanna Rothman - Fri, 11/21/2014 - 16:10

If you read my Three Alternatives to Making Smaller Stories, you noticed one thing. In each of these examples, the problem was in the teams’ ability to show progress and create interim steps. But, what about when you have a “wicked” problem, when you don’t know if you can create the answer?

If you are a project manager, you might be familiar with the idea of “wicked” problems from   from the book Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms. If you are a designer/architect/developer, you might be familiar with the term from Rebecca Wirfs-Brock’s book, Object Design: Roles, Responsibilities, and Collaborations.

You see problems like this in new product development, in research, and in design engineering. You see it when you have to do exploratory design, where no one has ever done something like this before.

Your problem requires innovation. Maybe your problem requires discussion with your customer or your fellow designers. You need consensus on what is a proper design.

When I taught agile to a group of analog chip designers, they created landing zones, where they kept making tradeoffs to fit the timebox they had for the entire project, to make sure they made the best possible design in the time they had available.

If you have a wicked problem, you have plenty of risks. What do you do with a risky project?

  1. Staff the project with the best people you can find. In the past, I have used a particular kind of “generalizing specialist,” the kind where the testers wrote code. The kind of developers who were also architects. These are not people you pick off the street. These are people who are—excuse me—awesome at their jobs. They are not interchangeable with other people. They have significant domain expertise in how to solve the problem. That means they understand how to write code and test.
  2. Help those generalizing specialists learn how to ask questions at frequent points in the project. In my inch-pebble article, I said that with a research project, you use questions to discover what you need to know. The key is to make those questions small enough, so you can show progress every few days or at least once week. Everyone in the project needs to build trust. You build trust by delivering. The project team builds trust by delivering answers, even if they don’t deliver working code.
  3. You always plan to replan. The question is how often? I like replanning often. If you subscribed to my Reflections newsletter (before the Pragmatic Manager), back in 1999, I wrote an article about wicked projects and how to manage the risks.
  4. Help the managers stop micromanaging. The job of a project manager is to remove obstacles for the team. The job of a manager is to support the team. Either of those manager-types might help the team by helping them generate new questions to ask each week. Neither has the job of asking “when will you be done with this?” See Adam Yuret’s article The Self-Abuse of Sprint Commitment.

Now, in return, the team solving this wicked problem owes the organization an update every week, or, at the most, every two weeks about what they are doing. That update needs to be a demo. If it’s not a demo, they need to show something. If they can’t in an agile project, I would want to know why.

Sometimes, they can’t show a demo. Why? Because they encountered a Big Hairy Problem.

Here’s an example. I suffer from vertigo due to loss of (at least) one semi-circular canal in my inner ear. My otoneurologist is one of the top guys in the world. He’s working on an implantable gyroscope. When I started seeing him four years ago, he said the device would be available in “five more years.”

Every year he said that. Finally, I couldn’t take it anymore. Two years ago, I said, “I’m a project manager. If you really want to make progress, start asking questions each week, not each year. You won’t like the fact that it will make your project look like it’s taking longer, but you’ll make more progress.” He admitted last year that he took my advice. He thinks they are down to four years and they are making more rapid progress.

I understand if a team learns that they don’t receive the answers they expect during a given week. What I want to see from a given week is some form of a deliverable: a demo, answers to a question or set of questions, or the fact that we learned something and we have generated more questions. If I, as a project manager/program manager, don’t see one of those three outcomes, I wonder if the team is running open loop.

I’m fine with any one of those three outcomes. They provide me value. We can decide what to do with any of those three outcomes. The team still has my trust. I can provide information to management, because we are still either delivering or learning. Either of those outcomes provides value. (Do you see how a demo, answers or more questions provides those outcomes? Sometimes, you even get production-quality code.)

Why do questions work? The questions work like tests. They help you see where you need to go. Because you, my readers, work in software, you can use code and tests to explore much more rapidly than my otoneurologist can. He has to develop a prototype, test in the lab and then work with animals, which makes everything take longer.

Even if you have hardware or mechanical devices or firmware, I bet you simulate first. You can ask the questions you need answers to each week. Then, you answer those questions.

Here are some projects I’ve worked on in the past like this:

  • Coding the inner loop of an FFT in microcode. I knew how to write the inner loop. I didn’t know if the other instructions I was also writing would make the inner loop faster or slower. (This was in 1979 or so.)
  • Lighting a printed circuit board for a machine vision inspection application. We had no idea how long it would take to find the right lighting. We had no idea what algorithm we would need. The lighting and algorithm were interdependent. (This was in 1984.)
  • With clients, I’ve coached teams working on firmware for a variety of applications. We knew the footprint the teams had to achieve and the dates that the organizations wanted to release. The teams had no idea if they were trying to push past the laws of physics. I helped the team generate questions each week to direct their efforts and see if they were stuck or making progress.
  • I used the same approach when I coached an enterprise architect for a very large IT organization. He represented a multi-thousand IT organization who wanted to revamp their entire architecture. I certainly don’t know architecture. I know how to make projects succeed and that’s what he needed. He used the questions to drive the projects.

The questions are like your tests. You take a scientific approach, asking yourself, “What questions do I need to answer this week?” You have a big question. You break that question down into smaller questions, one or two that you can answer (you hope) this week. You explore like crazy, using the people who can help you explore.

Exploratory design is tricky. You can make it agile, also. Don’t assume that the rest of your project can wait for your big breakthrough.  Use questions like your tests. Make progress every day.

I thank Rebecca Wirfs-Brock for her review of this post. Any remaining mistakes are mine.

Categories: Blogs

Wer ist eigentlich … Christoph Schmiedinger?

Scrum 4 You - Fri, 11/21/2014 - 08:21

Wie beschreibst du deinen Eltern/ Freunden deinen Arbeitsalltag bei Boris Gloger Consulting?
Viele verbinden mit Unternehmensberatung gut gekleidete Menschen, viel reisen, Überstunden en masse und schöne PowerPoint-Foliensätze. Im Wesentlichen stimmen einige dieser Aspekte, doch ich denke, dass es bei Boris Gloger Consulting doch ein wenig anders abläuft als in klassischen Beratungen. Meiner Familie und Freunden beschreibe ich meinen Arbeitsalltag immer als äußerst abwechslungsreich und herausfordernd. In der Hauptsache bin ich dazu da, anderen Menschen zu helfen, ein Produkt erfolgreicher zu entwickeln. Dazu verwende ich moderne Ansätze, die in vielen Organisationen Widerstand hervorrufen. Auch das ist ein Grund, warum ich mit an Bord bin. Neben den Projekten beschreibe ich meinen Freunden auch oft unsere differenzierte Arbeitsweise im Unternehmen selbst, etwa das Prinzip der Freiwilligkeit oder den Freiraum, der uns gegeben wird. Viele können das nicht nachvollziehen, weil sie nicht glauben können, dass eine Firma auf Basis dieser Prinzipien funktionieren kann.

Welchen Beruf wolltest du als Kind unbedingt ergreifen?
Als Kind wollte ich die klassischen Abenteuer-Berufe wie Feuerwehrmann oder Polizist ergreifen. Vielleicht war es aber auch die Hilfsbereitschaft, die mich dazu motivierte. Ich denke, dass ich mit meiner Berufswahl als Consultant diese Wünsche zumindest teilweise ausleben kann. Immerhin ist jedes Projekt immer wieder ein Abenteuer und ich liebe es, anderen Menschen zu zeigen, dass sie ihren Arbeitsalltag erleichtern und gleichzeitig erfolgreich sein können.

Wie siehst du deine bisherige Karriere? Viel Zufall oder überwiegend sorgfältige Planung?
Meine bisherige Karriere war überwiegend sorgfältig geplant. Ich habe bereits kurz vor meiner Matura (Abitur) den Entschluss gefasst, gleichzeitig einen verantwortungsvollen Job anzunehmen und mein Studium am Abend und Wochenende zu absolvieren. Fünf Jahre später bin ich froh, diesen Weg gewählt zu haben. Ich erkenne, wie viel Vorsprung ich durch meine zusätzlichen fünf Jahre Berufserfahrung nach meinem Studienabschluss hatte oder noch immer habe. Auch der Weg ins Consulting war geplant, da ich nach fünf Jahren im gleichen Unternehmen „raus“ in die weite Welt und „Neues“ kennenlernen wollte. Da mich agile Methoden bereits im letzten Unternehmen und auch während meines Studiums fasziniert haben, fiel die Wahl auf eine Unternehmensberatung mit Fokus auf agile Methoden und dann letztendlich auf Boris Gloger Consulting.


Gibt es ein bestimmtes Ritual in der Arbeitswoche, auf das du nicht verzichten könntest?
Interessanterweise habe ich bei dieser Frage als Erstes den Weekly Report, den wir dem Kunden zu Abschluss der Arbeitswoche schicken, im Kopf. Für mich ist dieses „Absenden“ der formale Abschluss der Projektwoche, mit dem ich meine Gedanken für das Projekt zum Wochenende ruhen lasse.

Unter all den Projekten, die du für Boris Gloger Consulting realisiert hast: Welches ist dein All-Time-Favourite?
Ich hatte erst ein Projekt bei Boris Gloger Consulting, das ich nun bereits seit mehr als sechs Monaten begleite. Ich denke aber, dass es durchaus einer der All-Time-Favourites werden könnte. Die große Herausforderung in dem Projekt waren die sehr unterschiedlichen Typen und Charaktere (Entwickler, SAP-Berater und Anwender), die erst zur Zusammenarbeit bewogen werden mussten. Es war großartig zu sehen, wie diese Entwicklung über den Lauf der Sprints zunehmend stattgefunden hat, so dass wir nach ein paar Monaten ein hoch performantes und gut zusammenarbeitendes Team geschaffen haben.

Drängende Kundenanfragen, E-Mail-Flut, Meeting-Marathon oder als Consultant jeden Tag an einem anderen Ort: Was ist dein Geheimrezept, um im hektischen Arbeitsalltag einen kühlen Kopf zu bewahren?
Bereits während meines Studiums, das ich neben meinem 40-Stunden-Job absolviert habe, habe ich mir angewöhnt, ein gutes Zeitmanagement zu betreiben. Dazu gehört neben einer ordentlich gepflegten To-Do-Liste auch die richtige Einstellung bzw. Herangehensweise. Ich versuche beispielsweise, alle Aufgaben so früh wie möglich abzuschließen, auch wenn die Deadline noch weit entfernt scheint. Das hilft mir, nicht zu sehr in Stress zu geraten, wenn diese Termine näher rücken. Zusammengefasst ist mein Rezept ein strukturiertes und zeitnahes Abarbeiten der zu erledigenden Themen.

Was ist für dich das Besondere an der Arbeit bei Boris Gloger Consulting?
Das Besondere ist einerseits das Projektumfeld, das äußerst spannend und herausfordernd ist. Immer wieder gibt es neue Projekte, in denen man am liebsten selber mitwirken will, weil das Problem oder die Situation einfach nur aufregend und spannend ist. Andererseits ist es die Atmosphäre im Unternehmen selbst. Alles basiert auf Freiwilligkeit und jeder kann sich einbringen, wo er seine eigenen Stärken sieht, solange es zum Unternehmensziel beiträgt. Dieser Freiraum ist anfangs ungewohnt, auch ich habe ein paar Wochen bis Monate gebraucht, um mich damit zurecht zu finden. Nun bin ich in vielen Themen engagiert und weiß, wo ich zu den Unternehmenszielen beitragen kann und das auch tue.

Gibt es eine Marotte, mit der du deine Kollegen regelmäßig auf die Palme bringst?
Da ich ein sehr ruhiger und friedliebender Mensch bin, sind es wenn nur kleine Marotten, wie beispielsweise meine Penibilität beim Review von Blogbeiträgen, in denen ich regelmäßig viel in der Wortwahl und Satzstellung ändere.

Was machst du in deiner Freizeit, um runterzukommen?
In meiner Freizeit verbringe ich viel Zeit mit meiner Lebensgefährtin, auch weil wir uns unter der Woche nicht bzw. äußerst selten sehen. Dabei stehen nicht außergewöhnliche Hobbies, sondern einfach die gemeinsame Zeit im Vordergrund. Das heißt, wir unternehmen total unterschiedliche Dinge und gerade das, worauf wir spontan Lust haben. Gerne komme ich aber auch allein „runter“, meist bei sportlichen Aktivitäten wie Rad fahren, Snowboarden oder Tauchen.

Scrum ist für mich…
die perfekte Methode, ein großes Vorhaben strukturiert und erfolgreich zum Ziel zu bringen und zugleich das Team zufriedener mit seiner Arbeit zu machen.

Categories: Blogs

New SAFe Principles and Revised LSE Big Picture

Agile Product Owner - Thu, 11/20/2014 - 23:21

Ok, so these are not the same topic, but they are related, so I thought one blog post could cover both … so …

We’ve been working on highlighting the principles behind SAFe and SAFe LSE. In future versions of both, we’ll have a tab for Principles on the left, including a nav to elaborations on each principle topic. Then, everything on the right will be practices. It will look something like this:

Screen Shot 2014-11-20 at 10.34.44 AM

Principles on the left. Practices on the right.

And perhaps a new meta-message, SAFe: Proven Practices from Immutable Principles.

In moving forward with this plan, we have established a draft set of Principles that will be applied to both versions of the framework. Our current WIP is here:

Screen Shot 2014-11-20 at 10.37.51 AM


And finally, to make sure that we both really get our money’s worth on this post, we have a new version of the LSE Big Picture. We aren’t stopping, but the pace of needed change is slowing down, so something a lot like this will be likely when we go live with the development site in January.

SAFE LSE BP Version many

SAFe LSE BP Version many


Categories: Blogs

Agile Quick Links #26

Notes from a Tool User - Mark Levison - Thu, 11/20/2014 - 21:15
Walt Disney curiosity quoteSome interesting reading for the Agile community:
Categories: Blogs

The Napoleon Corporal

Leading Agile - Mike Cottmeyer - Thu, 11/20/2014 - 14:08

In my previous post, Replacing Backlog Grooming, I wrote about leveraging a Product Owner (PO) Team instead of the “Scrum” team in Progression Workshops (backlog grooming).

To clarify, the members of the PO teams are mainly populated by a Product Owner (Product Lead) and facilitator (could be a Scrum Master), but from there we’ll include others like a development lead, a testing lead, and an architect. We use the team construct over a single person because we’re operating at scale, with multiple delivery teams.  The Leads and Architects are thinking bigger-picture strategy and are aware of external dependencies that need to be avoided or dealt with.  The goal is to progress work along, getting it ready for the delivery team.  To help bridge the knowledge gap with the delivery teams, there are members of the delivery teams who will attend the progression workshops, mostly to play the part of the Napoleon Corporal. (I call them that, not the client)

For those unfamiliar with the term Napoleon Corporal:

Napoleon recognized how vital it was to have an enlisted soldier in the planning process. During every Battle Plans briefing Napoleon would have a Corporal shine his boots knowing that the Corporal was listening. Once the General Staff finished the brief, Napoleon would look down at the Corporal and asked if he understood the plan. If the Corporal answered, Yes Sir! The General would have his Staff execute the plan. If the Corporal answered, No Sir! The General would have the General Staff rewrite the plan.

It doesn’t matter if you’re doing textbook Scrum or something at scale.  Your people still need a shared understanding. If not, you’re going to start seeing a lot of delays and a lot of rework.

When you have a Scrum or Kanban team, you’re not always getting “A” players. Sometimes it’s a real mixed bag.  To expand the military metaphor, sometime you don’t get a Corporal. Sometimes, you get yourself a Boot Private.  If work is outsourced, developers and testers won’t necessarily have domain experience. They might be great coders or testers but not experienced in financial, medical, or other verticals.  You need to get them to understand the mission and the mission is not necessarily to write and test code. The shared understanding is how to solve a problem for the customer.

Depending on the experience of the delivery team, the conversation (and backlog) may need to be simplified enough to be understood by someone junior to a Corporal.


The post The Napoleon Corporal appeared first on LeadingAgile.

Categories: Blogs

9th International PMI Poland Chapter Congress

Leading Answers - Mike Griffiths - Thu, 11/20/2014 - 05:31
I will be in Warsaw next week for the 9th International PMI Poland Chapter Congress – themed “Mission Impossible”. I am very much looking forward to it and sessions like the “Global Challenges of Mega Projects” by Virginia Greiman of... Mike Griffiths
Categories: Blogs

Three Alternatives for Making Smaller Stories

Johanna Rothman - Wed, 11/19/2014 - 20:02

When I was in Israel a couple of weeks ago teaching workshops, one of the big problems people had was large stories. Why was this a problem? If your stories are large, you can’t show progress, and more importantly, you can’t change.

For me, the point of agile is the transparency—hey, look at what we’ve done!—and the ability to change. You can change the items in the backlog for the next iteration if you are working in iterations. You can change the project portfolio. You can change the features. But, you can’t change anything if you continue to drag on and on and on for a give feature. You’re not transparent if you keep developing a feature. You become a black hole.

Managers start to ask, “What you guys doing? When will you be done? How much will this feature cost?” Do you see where you need to estimate more if the feature is large? Of course, the larger the feature, the more you need to estimate and the more difficult it is to estimate well.

Pawel Brodzinski said this quite well last year at the Agile conference, with his favorite estimation scale. Anything other than a size 1 was either too big or the team had no clue.

The reason Pawel and I and many other people like very small stories—size of 1—means that you deliver something every day or more often. You have transparency. You don’t invest a ton of work without getting feedback on the work.

The people I met a couple of weeks ago felt (and were) stuck. One guy was doing intricate SQL queries. He thought that there was no value until the entire query was done. Nope, that’s where he is incorrect. There is value in interim results. Why? How else would you debug the query? How else would you discover if you had the database set up correctly for product performance?

I suggested that every single atomic transaction was a valuable piece. That the way to build small stories was to separate this hairy SQL statement was at the atomic transaction. I bet there are other ways, but that was a good start. He got that aha look, so I am sure he will think of other ways.

Another guy was doing algorithm development. Now, I know one issue with algorithm development is you have to keep testing performance or reliability or something else when you do the development. Otherwise, you fall off the deep end. You have an algorithm tuned for one aspect of the system, but not another one. The way I’ve done this in the past is to support algorithm development with a variety of tests.

Testing Continuum from Manage It!This is the testing continuum from Manage It! Your Guide to Modern, Pragmatic Project Management. See the unit and component testing parts? If you do algorithm development, you need to test each piece of the algorithm—the inner loop, the next outer loop, repeat for each loop—with some sort of unit test, then component test, then as a feature. And, you can do system level testing for the algorithm itself.

Back when I tested machine vision systems, I was the system tester for an algorithm we wanted to go “faster.” I created the golden master tests and measured the performance. I gave my tests to the developers. Then, as they changed the inner loops, they created their own unit tests. (No, we were not smart enough to do test-driven development. You can be.) I helped create the component-level tests for the next-level-up tests. We could run each new potential algorithm against the golden master and see if the new algorithm was better or not.

I realize that you don’t have a product until everything works. This is like saying in math that you don’t have an answer until you have the finished the entire calculation. And, you are allowed—in fact, I encourage you—to show your interim work. How else can you know if you are making progress?

Another participant said that he was special. (Each and every one of you is special. Don’t you know that by now??) He was doing firmware development. I asked if he simulated the firmware before he downloaded to the device. “Of course!” he said. “So, simulate in smaller batches,” I suggested. He got that far-off look. You know that look, the one that says, “Why didn’t I think of that?”

He didn’t think of it because it requires changes to their simulator. He’s not an idiot. Their simulator is built for an entire system, not small batches. The simulator assumes waterfall, not agile. They have some technical debt there.

Here are the three ways, in case you weren’t clear:

  1. Use atomic transactions as a way to show value when you have a big honking transaction. Use tests for each atomic transaction to support your work and understand if you have the correct performance on each transaction.
  2. Break apart algorithm development, as in “show your work.” Support your algorithm development with tests, especially if you have loops.
  3. Simulate in small batches when you have hardware or firmware. Use tests to support your work.

You want to deliver value in your projects. Short stories allow you to do this. Long stories stop your momentum. The longer your project, and the more teams (if you work on a program), the more you need to keep your stories short. Try these alternatives.

Do you have other scenarios I haven’t discussed? Ask away in the comments.

This turned into a two-parter. Read Make Stories Small When You Have “Wicked” Problems.

Categories: Blogs

Make Concepts Explicit when Fixing Bugs

Dear Junior

To find implicit concepts and make them explicit is a very powerful way to improve code. But, sometimes it is hard to judge beforehand which concept is important enough to make explicit. We try to make good judgements, but sometimes we miss.

But, no reason to despair, we can take Time as our helpful aid. So, instead of everything perfect from start, we continuously perfect it whenever we find a reason. Two of the topmost reasons are either a bug appearing or further development of the code.

Let me for now fokus on the case of when a bug appears. If the code does not behave the way we intended it to do, then there is most often a place in the code that was to convoluted. In that convoluted state, subtle misunderstandings and simple mistakes could hide. The solution is to clarify the code until it is obvious whereof the mistake consists.

Things get clearer by examples, so let me clarify what I mean with a very minimal example, the story about a bug and its fix.
In real life, more or less a decade ago, I worked on a project where we did a batched import of records coming from an external source. The code looked roughly like this following in the class ImportCron.
public class ImportCron {
    private RecordImporter importer;    private Logger logger;
    void runImport()  {        List records = importer.listWaitingRecords();        logger.log(Level.INFO, "Importing records: " + records.size());        for ( Object rec : records) // imports each of the records in turn    …    }
Now, the import was run once a minute, but most of the time there where non records waiting.  Problem was the import log became filled with rows saying "Importing records: 0" so we had to grep out the non-zero lines each time we wanted to look at what was happening.
One of those days I got tired of this, fired up the editor, and wrapped the logging in an if statement to filter out all those zero-import writes.
    void runImport()  {        List records = importer.listWaitingRecords();        if (records.size() == 0)            logger.log(Level.INFO, "Importing records: " + records.size());        for ( Object rec : records) // imports each of the records in turn    …    }
A few days later we released during lunch, which was the best time for our users. The deploy went smooth, apps started up as expected, and soon it was time for the first import "tick".
Within a minute, import was run the first time, and the log line read:<timestamp> Importing records: 0While standing confused, a minute went by, and the log line read:<timestamp> Importing records: 0Another minute went by … and no log line.While firing up my editor to check the code, another minute went by and a third log line appeared:<timestamp> Importing records: 0A colleague of mine looking in the database calmly reported "We just imported three records".It only took me a split of a second to realise my mistake once I had the code in front of me.
    void runImport()  {        List records = importer.listWaitingRecords();        if (records.size() == 0)            logger.log(Level.INFO, "Importing records: " + records.size());        for ( Object rec : records) // imports each of the records in turn
Obviously my spine reflex for coding "check for zero" made me write the boolean expression the wrong way around. By the way, did you capture that mistake at first glance in the code on my first description? Confirmation bias is a nasty thing.
Now, I must say this kind of bugs are pretty uncommon, bugs that are typos or simply mispunching the keys. Most bugs in my opinion are rather that pieces of code subtly misunderstand each other.
Well there are at least two ways of fixing this code. The obvious, and fastest would be to quickly change "==" to "!=". However, humbled by the mistake I had done in the first place, I realised that that kind of hasty coding was what got me in the trouble in the first place.
One of my coding mantras since long have been "Code should mean something, not just do something". So, a better way out would be to make the code more meaning-ful. From Eric Evans I learned the phrase "Make implicit concepts explicit", which says the same thing in this context, but gives a better guiding direction forward.
I took to the challenge of fixing the bug by finding what implicit concepts had been missed, and making them explicit until it was blatantly obvious that the code was wrong. An added benefit would be to be able to make a test proving the code was wrong.
Extracting the boolean condition to a method of its own would force me to spell out the meaning of that piece of code.
    void runImport()  {        List records = importer.listWaitingRecords();        if (containsRecords(records))            logger.log(Level.INFO, "Importing records: " + records.size());        for ( Object rec : records) // imports each of the records in turn
    static boolean containsRecords(List records) {        return records.size() == 0;    }
Granted, this is more code than I started with - but I think the code is more "to the point" (phrased inspired by Rickard Öberg, another of the great programmers).
At least this made me able to write a test
    @Test    public void shouldConsiderEmptyListNotContainingRecords() {       Assert.assertFalse(ImportCron.containsRecords(Collections.EMPTY_LIST));    }
Well, at least this is what the test would look today - at the time JUnit looked slightly different.
Anyway, now I have a failing test. Claiming "the empty list does not contain records" is simply false - as proven by the test. We safely update the code to fix the bug.
    static boolean containsRecords(List records) {        return records.size() != 0;    }
Upon which the test switched to green as expected.
During this "refactor -> put under test -> fix" something interesting has happened. The concept "import list contains records" that hitherto had been implicitly represented by the technical "records.size() != 0" has now been made explicit and given a name "containsRecords".
It might be claimed that the main benefit in this example was derived from the drive to put code under test before making a change. Undeniably, that is a point, but I think it only tells half the tale. 
Simply putting things under test can be done in a myriad of ways, and I have seen several very technology-based efforts. I do not think those efforts have paid off handsomely. Mostly the code get cut along technical lines to push in tests in the gaps. But, the code does not get more comprehensible over time.
Focusing on "make implicit concepts explicit" have been a more productive course for me when working with code.
ps My team-mates did not force me to skip lunch to fix the bug. We went out together, and when we came back satisfied and rested, I sat down and fixed the code. We released the fix during lunch-time the day thereafter.

Categories: Blogs