Skip to content

Blogs

Managing Technical Debt with SonarQube

TV Agile - Mon, 02/09/2015 - 19:31
This talk discusses technical debt, the code quality factors, the SonarQube’s core ideas and its main features that simplify the process of tracking and improving software quality. SonarQube is an open source quality platform that makes it radically easier to track, manage, enhance the overall quality of your code and pay your technical debt on […]
Categories: Blogs

Agile Culture –> Self-Managing People

Agilitrix - Michael Sahota - Mon, 02/09/2015 - 16:49

Four years ago, I argued that Agile is a Culture System focussed on Collaboration and Cultivation. We may build on and refine this understand to see that Agile points towards a higher level of organizational consciousness and the benefits that come with it. In particular, Agile is about valuing people and setting them free to deliver.

The Agile Manifesto & Principles

Let’s use the Laloux Culture Model as a lens for understanding the Agile Manifesto. If you haven’t read about this yet, it is fantastic – go read it now – otherwise this post will not make much sense.

When we colour code each of the manifesto statements to match various stages of consciousness we get:

Individuals and interactions over processes and tools (Green)
Working software over comprehensive documentation (Orange)
Customer collaboration over contract negotiation (Green)
Responding to change over following a plan (Teal)

We see that the Agile manifesto is a mix of ideas from different levels.

Agile Principles
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (Green)
  • Welcome changing requirements, even late in  development. Agile processes harness change for the customer’s competitive advantage. (Teal)
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (n/a)
  • Business people and developers must work together daily throughout the project. (Green)
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. (Green)
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. (n/a)
  • Working software is the primary measure of progress. (Orange)
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (Teal)
  • Continuous attention to technical excellence and good design enhances agility. (Teal)
  • Simplicity–the art of maximizing the amount of work not done–is essential. (n/a)
  • The best architectures, requirements, and designs emerge from self-organizing teams. (Teal)
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Teal)

Note: Some principles are not colour coded since I didn’t really see how they fit. If you have ideas, please post a comment.

Agile is Teal/Green

When we tally up the results, we get the following for Agile Culture:

  • 6 – Teal Stage – Self-management, Distributed power, and emergence. 
  • 5 – Green Stage – People: purpose, values and empowerment
  • 2 – Orange Stage – Achievement

In a diagram, it looks like this:

Agile Culture

The Agile Manifesto is pointing to a way of working that is at the Teal/Green stage. Elements of Scrum such as emergence and self-organizing teams are very closely connected with the Teal stage.

In summary, Agile Culture is about organizations operating at a higher level of consciousness with self-managing people.

Implications for Using Agile

For organizations at the orange stage (most large companies) Agile will be experienced as a disruptive force. As all the elements of culture need to shift together, Agile will by necessity be watered down or contained. This is what we typically see – Agile Adoption – with Enterprise Agile or Scaling Agile.

The main challenge for Agile Culture is that it is only a partial specification for operating at a Teal/Green stage. As can be see from Whole Agile, we need to consider other cultural and organizational elements for a holistic solution. We must look beyond Agile to allow Agile to succeed. This is the path of organizational transformation.

The post Agile Culture –> Self-Managing People appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Culture Change: Reinventing Organizations The following infographic adapted from Frederic Laloux’s Reinventing Organizations shows:...
  2. Laloux Culture Model Looking for a way to help evolve your organization’s culture? Frederic...
  3. People over Process – Win with People Success comes from Valuing People When we simplify the Agile...

YARPP powered by AdBistroPowered by

Categories: Blogs

Entscheidungsgremien: Erfolgsfaktor in agilen Projekten?

Scrum 4 You - Mon, 02/09/2015 - 08:45

In einem unserer Projekte ging es darum, einen Systemverbund zu stabilisieren, der bisher durch eine fehlerverursachende Schnittstelle nur eingeschränkt genutzt werden konnte. Im Vorgängerprojekt sollten die beiden Systeme zusammengeschalten werden – es wurde klassisch abgewickelt und musste schließlich wegen Erfolglosigkeit gestoppt werden. Wegen der guten Erfahrungen mit Scrum in anderen Projekten lag es nahe, im zweiten Anlauf den agilen Ansatz zu wählen – hier kam ich ins Spiel. Und bevor ich weitererzähle, hier mein Appell gleich zu Beginn: Seid bereit, das Management aktiv an die Hand zu nehmen. Sie werden es euch danken!

Klassische Wünsche im agilen Rahmen

Schon in der Setup-Phase wurde klar, dass im vorherrschenden Umfeld ein tatsächlich agiles Projektvorgehen eine wahre Herausforderung werden wird. Erstens lastete hoher Druck auf dem Projekt, die Systeme endlich stabil zu bekommen und jede Form von Mehrkosten zu vermeiden. Zweitens wurde das Projekt noch mit einem zusätzlichen Gesamtprojektleiter, der übergeordnet die Verantwortung für das Projekt trug, besetzt. Und drittens hatten die entscheidenden Personen, allen voran das Top Management in Form eines Lenkungskreises, alles andere als agile Ansätze im Sinn. Beginnend mit der Forderung nach einem Reporting mit dem Fokus auf Budget und Zahlen kam auch schnell die Frage nach dem „großen“ Projektplan über die angesetzten 6 Monate auf. Was wird bis Datum XY geliefert und viel wichtiger: Was kostet dieses Unterfangen?

Ein Schritt zurück, um vorwärts zu kommen

Um dem Management einen groben Projektplan zu bieten, erarbeiteten die Product Owner mit Unterstützung der ScrumMaster einen physischen Releaseplan mit Post-Its. Dabei planten sie nach dem Eisberg-Prinzip: die kommenden Sprints detailliert und die zukünftigen Sprints auf höherer Ebene. Mit diesem Instrument konnten sie nun auch auf Gesamtprojektsicht einen Plan vorweisen. Anfangs wurde das noch skeptisch beäugt und als schwammig kritisiert. Das größte Hindernis war dabei wohl, dieses Nichtvorhersagen-Können zu akzeptieren. In traditionellen Projekten gibt man sich von Anfang an der Illusion hin, alles bis zum letzten Tag hin genauestens geplant und damit im Griff zu haben. Den Schritt zurück zu machen und zu akzeptieren, dass der Plan sehr wahrscheinlich so nicht eintreten wird, ist schwierig, aber notwendig. Es gelang in diesem Projekt und im Laufe der Zeit entwickelte sich der Releaseplan zu einem zentralen Planungsinstrument.

IMG_0464 Kopie 3

Sehen, worüber wir reden

Trotz des Releaseplans traf das Management in seinem Lenkungskreis (in dem nur der Gesamtprojektleiter, aber kein Product Owner oder ScrumMaster vertreten war) Entscheidungen, die mehr oder weniger große Auswirkungen auf unser Projekt und unseren Releaseplan hatten. Jedes Mal passten die Product Owner resigniert den kompletten Releaseplan an die neuen Entscheidungen an. Bei der x-ten Diskussion über Inhalt und Budget nahmen wir ScrumMaster schließlich das Zepter in die Hand. Wir forderten das Management auf, seine Diskussionen zu neuen Entscheidungen direkt mit uns – den ScrumMastern und Product Ownern – vor unseren Artefakten zu führen und Befürchtungen mit uns zu besprechen. Um es kurz zu machen: Das war die beste Entscheidung, die wir je treffen konnten. Noch nie zuvor hatte es zwischen dem Management (dem Lenkungskreis) und den Projektverantwortlichen einen so regen Austausch über den Scope und das Budget des Projekts gegeben. Alle Unklarheiten wurden geklärt und wir erzielten ein gemeinsames Commitment. Die Teams hielten dieses Commitment auch ein und lieferten.

Im Nachhinein hat es über den Erfolg des Projekts entschieden, dass das Top Management eingebunden wurde und sich mit den Verantwortlichen direkt und regelmäßig ausgetauscht hat. Wie oft hatten wir in der Vergangenheit das Gefühl gehabt, dass reines „Management by Desk“ praktiziert wurde, ohne zu wissen, wie es um das Projekt wirklich bestellt war. Wie oft hatte das Projektteam Angst vor folgenschweren Entscheidungen im Lenkungskreis. Angst davor, dass das Projekt gestoppt werden könnte, trotz erster nachweisbarer Erfolge. Angst vor Budgetkürzungen, die uns den notwendigen innovativen Freiraum nehmen könnten.

Daher nochmals mein dringender Appell: Nehmt euer Management an die Hand! Führt es zu den Artefakten und trefft dort mit den richtigen Personen die richtigen Entscheidungen — gerade und vor allem in traditionell geprägten Unternehmen.

Categories: Blogs

The Great Productivity Quotes Collection Revamped

J.D. Meier's Blog - Mon, 02/09/2015 - 00:32

A while back I put together a comprehensive collection of personal productivity quotes.   It’s a combination of the wisdom of the ages + modern sages.   It was time for a revamp.  Here it is:

The Great Productivity Quotes Collection

It's a serious collection of personal productivity quotes and includes lessons from the likes of Benjamin Franklin, Bruce Lee, Peter Drucker, Tony Robbins Voltaire, and more.

Productivity is Value Divided by Time

My favorite definition is a simple formula from Steve Pavlina:

Productivity = Value / Time

I like the formula because of it’s simplicity and because of the insight it provides.  If you want to increase your productivity, then you can increase the value or reduce the time it takes, or both.

One of the things I remind my colleagues in the halls of Microsoft is that value is the ultimate short-cut.  If you know what’s valued, you can eliminate or reduce all the waste in between.

Productivity Hot Spots

To organize the productivity quotes, I use a simple frame of productivity Hot Spots:

Action, Approach, Efficiency / Effectiveness, Energy Management, Failure, Focus, Goals, Improvement, Motivation and Mindset, Planning, Opportunity, Self-Awareness, and Time Management.

I find these buckets are useful for organizing principles, patterns, practices, and even quotes.   There are a lot of productivity quotes, so using this frame helps group the quotes into more manageable themes.

The Ultimate Formula for Personal Productivity

It sounds so simple when I say it now, but it took me a while to figure out the ultimate formula for personal productivity.   Here’s the formula:

Work on the right things, at the right time, the right way, with the right energy.

In other words, start with the right things.  Trim your tree of opportunity and focus on the right branches and leaves that will bear the most fruit.   Work on these things at the right time.  It’s easy to miss windows of opportunity and time changes what’s valued.   We also have better times in the day to work on things than others.   Work on things the right way.  This is really about using better techniques.  If have the wrong technique, then throwing hours and effort at something will just waste your time.  Lastly, work on things with the right energy.  Your energy is your force multiplier since you won’t get more time in the day.

A simple way to think of the way to optimize your productivity is to use your best energy for your best results.

I share a simple system and a comprehensive set of proven practices for personal productivity in my book, Getting Results the Agile Way. (It’s been a best seller in time management, and it helps you master productivity, time management, and work-life balance.)

Productivity Strategies

Believe it or not, quotes are not just neat and fun little sayings.   The right quotes are actually pithy ways to share strategies and insights.  They can completely change your game.

Here are a handful of some of the strategies that I’ve learned for improving productivity and many of these strategies are echoed in The Great Productivity Quotes Collection:

Less is more.

Focus on quality.

Quotas and quantity can help you achieve quality.  (If you learn from your process and apply it.)

Value is in the eye of the beholder and the stakeholder.

Find better techniques to multiply your results.

Enjoy the process.

Spend more time in your strengths, and less time in your weaknesses.

Pair up to amplify your talents and capabilities.

Focus on continuous improvement.

Manage your energy, not time.

Reduce the time you spend and you’ll innovate in your process.

Use timeboxing to invest time more intelligently. (Set limits and boundaries so you don’t over-spend in the wrong areas of your life.)

Work smarter, not harder.

Change your approach when it’s not working.

Test your results.

Productivity is Power

There are many ways to think about productivity.   I like to think of productivity as power.  I think of power as the ability to take action.   When you exercise your ability to take action and concentrate your effort and your focus, you can make amazing things happen in work and life.

Productivity is a powerful tool in your toolbox for personal empowerment.

As with anything, make sure you use the right tool for the job.  And that’s why I continue to fill my toolbox with several tools.  Otherwise, if all you have is a hammer, then everything looks like a nail.

You Might Also Like

The Great Personal Development Quotes Collection Revamped

The Great Leadership Quotes Collection Revamped

Happiness Quotes Revamped

Categories: Blogs

Ways of expressing estimates

George Dinwiddie’s blog - Sun, 02/08/2015 - 18:01

The way we express our estimates color both the way we think about the thing being estimated and the way our estimates are heard.

Single value

Quite often, when asked for an estimate, people will give a single value. “How long will this take?” “Three weeks.” If the level of trust is sufficient, and the points of reference are sufficiently aligned, then a single value may be fine. Expressing an estimated value as a single value leaves a lot unsaid, though. How confident are we about that value? If we’re wrong, what might the actual be?

We often find ourselves in trouble when one person gives an estimated value with one set of assumptions, and another person hears it with another set of assumptions. I might stress that my estimate of 2 days for a task is an optimistic one, assuming that no unforeseen problems crop up. You might hear it as an expression of the most likely value, with a small range of error around it. When the communications go further than from one person to the next, the likelihood of misinterpreting the context of assumptions goes way up. If you now communicate my estimate to your boss, they may interpret it as a commitment to that duration. The caveats and warnings tend to fade but the number is remembered.

Over/Under a value

When I learned orienteering in Boy Scouts, one of the lessons was, when finding your way out of the woods by compass, make sure you err to one side. That way, when you reached a road, you’d know which way to turn. If you tried to go directly to your intended destination, you could be on either side when you hit the road.

You can use a similar philosophy when using estimates. Estimating “not more than” or “not less than” can often give enough information to know which way to turn using single point estimation.

Single value with error bars

For some situation, estimating a minimum or maximum value may not be as helpful as a “most likely” value. We can indicate the confidence we have in this value with error bars. Those error bars might be specific minimum and maximum values, though that means we’ve got three separate values to estimate. I’m more likely to use percentages. I’ve often estimated the time required for vaguely described tasks with error bars of -50% and +100%. This seems unbalanced to some people, but looks more reasonable on a logarithmic scale. It also fits with the epidemic over-optimism of software development estimation.

Range

If you’re going to estimate the minimum and maximum possibilities, you might find that the estimated range is enough and you don’t need a most likely value. Beware how you communicate a range estimate, however. It’s all too frequent that the recipient hears just the endpoint they’d prefer. I’ve seen managers complain when a task estimated at 2 to 4 week comes in at 3 weeks, “but you said it could be done in 2 weeks.”

With a confidence level

You can express uncertainty of either a point estimate or a range estimate with a confidence level. “I’m 95% confident that this task can be completed within 2 weeks.” “It’s 95% sure that this work will take from 1 to 3 weeks.”

Sometimes a high confidence level is not what you’d prefer. When estimating user stories to determine how much work fits into a Scrum sprint, for example, using high-confidence estimates will result in taking on less work than you otherwise might attempt. Then, in accordance with Parkinson’s Law, the work expands to fill the allotted time. In such a situation, I recommend estimating at the 50% confidence level. I tell people that they should expect, in the long haul, to run short on time and run short on work in roughly equal amounts.

I don’t know how to estimate confidence levels with a precision that I would trust. I do know that estimating with mathematical models can give you a calculated confidence level. You can then use that confidence level to make decisions with surgical precision based on the odds of the estimation coming true. All of this is still, however, based on the fitness of the mathematical model and the accuracy of the input data.

Confidence levels are easily misunderstood by most people. I’ve often heard people complain that the weather report is inaccurate because it forecast a 30% chance of rain, and it didn’t rain.

Probability distribution

Going further than a confidence level, specifying a probability distribution for our estimate gives us precision at any desired confidence level. If it’s a Gaussian distribution, for instance, we can know their is a 50% chance of the actual being the median value or below. There’s a 97.5% chance of the actual being at or below two standard deviations above the mean.

Of course, the same caveats about fitness of the mathematical models and the accuracy of the input data apply to estimates expressed as probability functions. Empirical data shows that the probability distribution of completion time for a software development project is unlikely to be symmetrical, and therefore the Baussian distribution is a poor model. This leads people to use a Weibull distribution, instead, to model the skew that development time is more likely longer than shorter compared to the median time. The Weibull shape parameter, β, has a dramatic effect on the shape of the distribution, and therefore the fitness.

Unitless measures relative to other estimates

In reaction to the all-too-frequent problems that arise from giving estimates in units of time, sometimes people switch to unitless measures for their estimates. This allows relative estimation between comparable tasks. “This task and that one are about the same size.” Unitless estimation allows the estimate to “float” in absolute terms and be calibrated by past experience. “If we got about 42 units of work done last week, we expect to accomplish about 42 units of work this week.” If the speed of getting work done changes, then only the expectation needs to change; the work does not need to be re-estimated.

The most common unitless measure of the day seems to be story points. These are so-called because they represent the “size” of a functional slice of work called a user story. They’re often restricted to a “modified Fibonacci series” to represent the reduced accuracy of estimation as the size of the story increases.

The human mind is a subtle and wondrous thing. It seems to become better at estimating the size of one story against another when freed from the tyranny of measurements of time. I’ve noticed that teams starting with a completely arbitrary size reference (“Let’s call this fairly small story a ‘2’ and estimate the others relative to it”) seem to achieve consistent sizing more rapidly than those who start with a time-related reference (“Let’s call a story a ‘2’ if it will take about 2 uninterrupted ‘ideal’ hours”).

Sadly, it’s often too tempting for someone, particularly someone with sufficient power in the organization, to calibrate story points back to units of time. This generally negates the advantage of using a unitless measure, as people start thinking in terms of hours instead of points. It’s even worse when the calibration is made to “ideal” hours, as someone will surely complain “Why do the programmers only accomplish 5 hours of story points a day?” <sigh>

Story points are still expressed as numbers, and that tempts people to do more mathematical calculations than their accuracy and precision will reasonably support. The next level of estimate abstraction is to eliminate the numbers. People use many things to stand in for the numbers. One of the most creative is animals. Perhaps the most common is T-shirt sizes, XS, S, M, L, XL. While you can assume that a 10-point story is twice the size of a 5-point, and five times that of a 2-point, you can’t assume such a relationship between a Small, Medium, and Large story. This is another means to free the mind from what it thinks it should know, and let it operate on the subconscious level that often gives better results.

What do you think?

Have I omitted some useful ways to express estimates? Or ways, useful or not, that people tend to use? Have I mischaracterized any of these? Please leave a comment with your thoughts.

Categories: Blogs

Are agile trainers agile?

Scrum Breakfast - Sun, 02/08/2015 - 11:39
There are literally hundreds if not thousands of people out there who will train you to do Agile (and some will even try to convince you to be Agile). Some of them are certified, some are not. How many of them apply Agile to their own profession? I believe the answer is "not many," and I have realized that I was not one of them. This a-ha moment help me refine the purpose of my CST mentorship program.

When people say "Agile", most people are referring to the four values of the Agile Manifesto. While these are important, I believe the fundamental definition of Agility is contained not the four values, but the first statement: We are uncovering better ways of developing software by doing it and helping others do it. (emphasis added).

I don't develop software, I train people to do Scrum. Actually, I like to believe I enable them to turn their current project into their best project ever, so maybe this "training Scrum" is too limiting. Hmm... let's not go overboard just yet! So what would my manifesto look like? Here is the first draft:
We are uncovering better ways of teaching Scrum, by doing it and helping others to do it! -- Peter StevensThis has become the overarching goal of my CST Mentorship idea. Not just to get you through the TAC, but to create a community of like minded Agile trainers, who help each other to become better trainers, and help others to do the same.  It is no longer just a CST mentorship program, but a CST Mentoring Network.

P.S. I went looking for trainers who are active and transparent about mentoring. I have only found two (including myself):


Does anyone else belong on this list? Please let me know!


Categories: Blogs

The Great Personal Development Quotes Collection Revamped

J.D. Meier's Blog - Sat, 02/07/2015 - 23:54

“Knowing others is intelligence.  Knowing yourself is true wisdom.  Mastering others is strength.  Mastering yourself is true power.” -- Lao Tzu

A while back I put together a comprehensive collection of personal development quotes.   It’s a combination of the wisdom of the ages + modern sages.   It was time for a revamp.  Here it is:

The Great Personal Development Quotes Collection

It's a serious collection of personal development quotes and includes lessons from the likes of Buddha, Covey, Emerson,  Gandhi, Robbins, Ziglar, and more.

Personal Development is a Way to Realize Your Potential

Personal development is a process for life where you improve your awareness, your skills, your abilities, and your potential.  Personal development shapes your growth by developing your strengths, reducing your liabilities, and expanding what you’re capable of.

You improve your potential through self-awareness, habits, practice, and feedback.

Awareness is Half the Battle

A big part of personal development is simply awareness.  For example, when you know your Myers & Briggs Personality Type, you gain insight into whether you outwardly or inwardly focused, how you prefer to take in information, how you prefer to make decisions, and how you prefer to live your outer life.

Aside from better understanding your own patterns, you can also use it to understand other people’s behavior preferences, and you can adapt your style.  If you see somebody staring blankly at you during your presentation, it doesn’t mean they aren’t engaged.  They might just be an introvert processing the information in their own quiet way.

If you know your Conflict Style, you can tailor and adapt it to the situation, as well as better understand the mode that others are operating in.

There are many models and tools for self-awareness, but the goal is the same:  learn how to be more effective in more situations based on your individual strengths, abilities, and experience.

Action is the Other Half

Personal development is a verb.   You need to take action.  All the knowledge in the world doesn’t matter if you don’t apply it.  Even thoughts are habits that we haven’t learned how to measure.  When you apply what you learn, you can adjust what you learn based on feedback and results.

If you keep in mind that personal development is about continuously improving your thinking, feeling, and doing, then it’s easier to stay focused and to evaluate your results.

You can also approach personal development in a number of ways.  Just like martial arts, there are hard-styles and there are soft-styles.  In my experience, it helps to balance and blend hard-core skill building along with building the soft skills, especially interpersonal skills and your emotional intelligence.

Personal Development Requires a Growth Mindset

If you want to grow, you have to believe you can.

If you adopt a Growth Mindset, you can create a love of learning and a resilience that is the basis of great accomplishment in every area of work and life.

In the book, Mindset: The New Psychology of Success, author Carol Dweck shares a lot of science and stories around how our mindset limits or enables our growth.  If we believe that our abilities are fixed traits, and that we are either good or bad at something, then we have a Fixed Mindset.

If, on the other hand, you believe that you can get better through skills development, then you have a Growth Mindset.

If you’ve ever been in any sort of elite training, or specialized skills development or had a great mentor that provides deep feedback, it should be more than obvious to you how much growth and greatness is possible.

Adapting is the Key to Personal Development Success

So if you have a Growth Mindset, and you practice personal development, and you develop your self-awareness, then what will hold you back?

Simple.   The inability or lack of willingness for you to change your approach.

Darwin taught us that nature favors the flexible and Einstein said that doing the same thing over and over again and expecting different results is the definition of insanity.

And yet, how many people get stuck in a rut or hold themselves back through limiting thought patterns or behaviors?

One of the greatest things you can possible do for your future success is to learn how to change your approach with skill.

I could say so much more about personal development but at this point, I’d rather share what some of the greatest giants in personal development have had to say.  

Use The Great Personal Development Quotes Collection to stand on the shoulders of giants, and see further, as you look inward and upward.

And if you want a jumpstart in agile personal development, check out my best-selling book on productivity:  Getting Results the Agile Way.   It’s a simple system for meaningful results, and  it’s a way to use personal development to think better, feel better, and do better in all areas of your life.

Categories: Blogs

I've moved my blog over to http:/

Agile Coaching - Rachel Davies - Sat, 02/07/2015 - 20:40
I've moved my blog over to http://rachelcdavies.github.io/
Categories: Blogs

Automatically setting up pipelines

Putting the tea into team - Ivan Moore - Sat, 02/07/2015 - 14:05
Scripting the set up your continuous integration (CI) server is better than clicky clicky, but it might be possible to do even better. If you have many pipelines that are very similar then you might be able to fully automate their set up. A bit like having your own, in house version of Travis CI.

This article will use the GoCD terms "pipeline" and "stage" (a pipeline is somewhat like a "job" Jenkins, and a pipeline comprises one or more stages).

This article describes (at a very high level) the system my colleague Hilverd Reker and I have set up to automatically create pipelines. This has built on experience I gained doing something similar with Ran Fan at a previous client, and being the "customer" of an automated CI configuration system at another previous client.
InceptionWe have a pipeline in our CI server to automatically create the pipelines we want. We have called this "inception", after the film - I think Ran Fan came up with the name.

The inception pipeline looks for new things to build in new repositories, and sub directories within existing repositories, and creates pipelines as appropriate (using gomatic). (The inception process that Ran Fan and I wrote previously, looked for new things to build within "one large repo" (maybe the subject of a future blog article), and new branches of that repository).

The advantage of having this fully automated, compared to having to run a script to get the pipeline set up, is that it ensures that all pipelines get set up: none are forgotten and no effort is required.

Our inception job sets up a pipeline with only one stage, the bootstrap stage, which configures the rest of the pipeline. This keeps the inception job simple.
The bootstrap stageSome of the configuration of a pipeline depends upon the files in the repository that the pipeline is for. By making the first stage in the pipeline the bootstrap stage, it can configure the pipeline accurately for the files as they exist when the pipeline runs. If a pipeline is configured by the inception job, or by running a script, rather than a bootstrap stage, then its configuration will not reflect the files in the repository when they change, but rather how they were at the time the inception job, or script, ran. This would result in pipelines failing because they are not set up correctly for the files they are trying to use; hence we have the bootstrap as part of the pipeline itself to solve that problem.
Implementation notesOur bootstrap stage only alters the configuration of the pipeline if it needs to: it runs very quickly if no changes are needed. GoCD handles changes to the configuration of pipeline well. After the bootstrap stage has run, the subsequent stages run in the newly configured, or reconfigured, pipeline as expected. GoCD also handles the history of a pipelined reasonably well (but not always getting it right), even when it's configuration changes over time.
Example What would help right now would be an example - but that'll take time to prepare; watch this space (patiently) ...

Copyright ©2015 Ivan Moore 
Categories: Blogs

The Elephant in the Room (A Performance Review Conundrum)

Illustrated Agile - Len Lagestee - Fri, 02/06/2015 - 18:30

This was a question posted as a reply to the post Make Performance Reviews Meaningful. If you have questions of your own, feel free to reply to any post or submit your question on our Ask Anything page. One big question though: what do you do in the big reviews if an employee has had […]

The post The Elephant in the Room (A Performance Review Conundrum) appeared first on Illustrated Agile.

Categories: Blogs

Chief Agile Officer?

Bobtuse Bobservations - Bob MacNeal - Fri, 02/06/2015 - 13:00
Does anyone need a Chief Agile Officer? Not is this galaxy. Imagine an old-school and a new-school narrative: 1. Old-School Imagine a storied company called Hammer & Sons. Some 20 years after...

Bobtuse can be wildly informative
Categories: Blogs

ThoughtWorks London Opening Party

thekua.com@work - Fri, 02/06/2015 - 12:05

Last night ThoughtWorks had a welcoming party to celebrate the opening of our new London office, located in the heart of Soho.

I didn’t take as many photos I would have liked, but it was a fun event with a couple of musicians: Emily Lee, Scott McMahon and an amazing set of food prepared by Ed Baines (chef of Randall and Aubin).

OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA
Categories: Blogs

Schweigen ist Gold – vom Wert des passiven Zuhörens

Scrum 4 You - Fri, 02/06/2015 - 08:45

Wie leicht fällt es Ihnen, in einem Gespräch – sei es mit nur einem Partner oder in Meetings – bewusst mal länger zu schweigen? Besonders dann, wenn Sie zur Sache jede Menge Wesentliches und Kompetentes beitragen könnten und diesen inneren Drang verspüren, sich einbringen zu wollen. Immer wieder fällt mir in Kommunikationstrainings oder im Coaching auf, dass vor allem Führungsverantwortliche eher auf das Reden als auf das (längere) Schweigen programmiert sind. Häufig stecken da natürlich durchaus legitime Bedürfnisse dahinter, wie andere zu informieren, zu motivieren, zu überzeugen, sich durchzusetzen usw. Trotzdem ist der Erfolg des gut gemeinten Redeschwalls meistens gering. Fast jeder kennt den Begriff des aktiven Zuhörens als eine fundamentale und seit langem favorisierte Methode für erfolgreiche und dialogorientierte Kommunikation – das ist schon mal ein Fortschritt. Aber in der Praxis wird diese Kenntnis oder Erkenntnis, dass aktives Zuhören durchaus weiterbringen könnte, zu selten umgesetzt. Gründe siehe oben.

Deshalb hier mein eindringliches Plädoyer für passives Zuhören. Im Gegensatz zum obigen Kommunikations-Oldie liegt hier der alleinige Schwerpunkt erst mal auf Schweigen und stiller Wahrnehmung.

Schweigen ist Wahrnehmung

Schweigen hat in fernöstlichen Praktiken wie Meditation, Yoga etc. einen sehr hohen Stellenwert, aber durchaus auch Traditionen in westlich-religiösen Bezügen (z.B. im kontemplativen Gebet). Man kann von zwei Anwendungsgebieten sprechen: Zum einen vom Schweigen mit sich selbst, alleine und zum anderen von einem situativen Element in der Kommunikation mit anderen Menschen. Beide stehen in einem engen Zusammenhang und profitieren voneinander. Schweigen mit sich selbst fördert die Selbstwahrnehmung. Es fokussiert auf das Selbst, dient der Entspannung und Entschleunigung. Gerade für Führungskräfte kann das eine wesentliche Kraftquelle für gute agile Führung sein.

Schweigen im Dialog, also passives Zuhören, schärft neben der situativen Selbstwahrnehmung (wo stehe ich im Moment? Was passiert gerade? Was kommt bei mir an? Wie geht es mir damit? Wie wirkt mein Partner auf mich? etc.) auch die so wichtige Fremdwahrnehmung. Es gibt dem anderen die Zeit sich einzubringen, sich Raum zu nehmen. Und das schafft u.a. die derzeit allseits gepriesene Augenhöhe. Es kann das Gegenüber indirekt und elegant aufwerten und bestätigen. Angemessenes Schweigen fördert Vertrauen und führt oft überraschenderweise zu Lösungen und Entwicklung. Das bedeutet, der Wert bezieht sich nicht nur auf die sozialen Bezüge, sondern durchaus auch auf die sachlichen und fachlichen Themen. Schweigen ist auch eine Intervention und löst mehr aus, als man gemeinhin denkt.

Im 1973 erschienenen Roman „Momo“ von Micheal Ende fasziniert folgende Stelle zu meinem Thema:
„Was die kleine Momo konnte wie kein anderer, das war das Zuhören. Das ist doch nichts Besonderes, wird nun vielleicht mancher Leser sagen, zuhören kann doch jeder. Aber das ist ein Irrtum. Wirklich zuhören können nur recht wenige Menschen. Und so wie Momo sich aufs Zuhören verstand, war es ganz und gar einmalig. Momo konnte so zuhören, dass dummen Leuten plötzlich sehr gescheite Gedanken kamen. Nicht etwa, weil sie etwas sagte oder fragte, was den anderen auf solche Gedanken brachte nein, sie saß nur da und hörte einfach zu, mit aller Aufmerksamkeit und aller Anteilnahme. Dabei schaute sie den anderen mit ihren großen, dunklen Augen an, und der Betreffende fühlte, wie in ihm plötzlich Gedanken auftauchten, von denen er nie geahnt hatte, dass sie in ihm steckten. Sie konnte so zuhören, dass ratlose, unentschlossene Leute auf einmal ganz genau wussten, was sie wollten. Oder dass Schüchterne sich plötzlich frei und mutig fühlten. Oder dass Unglückliche und Bedrückte zuversichtlich und froh wurden. Und wenn jemand meinte, sein Leben sei ganz verfehlt und bedeutungslos und er selbst nur irgendeiner unter Millionen, einer, auf den es überhaupt nicht ankommt, und er ebenso schnell ersetzt werden kann wie ein kaputter Topf und er ging hin und erzählte das alles der kleinen Momo, dann wurde ihm, noch während er redete, auf geheimnisvolle Weise klar, dass er sich gründlich irrte, dass es ihn, genauso wie er war, unter allen Menschen nur ein einziges Mal gab und dass er deshalb auf seine besondere Weise für die Welt wichtig war. So konnte Momo zuhören!”

Diese sicher etwas idealisierte Episode zeigt doch wunderbar den Kern meiner Botschaft auf. Schweigen und passives Zuhören hat einen hohen Wert dort, wo es im Dialog angemessen praktiziert wird. Der Kabarettist Dieter Nuhr hat den Satz geprägt: „Öfter mal die Schnauze halten.“ Kurz, prägnant und flapsig trifft diese Aussage durchaus das Thema.

In dem bemerkenswerten Buch „Embodied Communication“ (2013, Huber Verlag) schlagen Maja Storch und Wolfgang Tschacher das „AAO Geschenk“ der Kommunikation vor:

  • Aufmerksam sein (auf die Situation, auf die eigenen Affekte und die des Gegenübers),
  • Augen auf (Wechsel zwischen direktem Blickkontakt und peripherem Gesichtsfeld),
  • Ohren auf (zwei Ohren genügen, aber die wirklich offen).

Nicht verschwiegen werden soll hier natürlich, dass (intensives) Schweigen durchaus auch missverstanden werden kann, z.B. im Sinne von Ablenkung, Gleichgültigkeit, sogar Ignoranz, Hilflosigkeit oder Schwäche.

Meine Empfehlungen zu diesem Thema heißen also:

  • Mehr bewusstes Schweigen in der Kommunikation zulassen und einsetzen
  • Zuerst für sich allein üben (gar nicht so einfach), das Seine partiell loslassen oder vorerst sein lassen
  • AAO nutzen
  • Dem Dialogprozess mehr vertrauen
  • Erfahrungen mit passivem Zuhören sammeln und den eigenen, angemessenen Weg suchen und finden.

Agile Führung nimmt Meta-Perspektiven ein. Sie hält eine gesunde Distanz, gibt Raum, versucht differenziert wahrzunehmen und setzt funktionale Interventionen.

font-470589_1280

Categories: Blogs

Clean Tests: Building Test Types

Jimmy Bogard - Thu, 02/05/2015 - 23:38

Posts in this series:

In the primer, I described two types of tests I generally run into in my systems:

  • Arrange/act/assert fully encapsulated in a single method
  • Arrange/act in one place, assertions in each method

Effectively, I build tests in a procedural mode or in a context/specification mode. In xUnit Test Patterns language, I’m building execution plans around:

There’s another pattern listed there, “Testcase Class per Feature”, but I’ve found it to be a version of one of these two – AAA in a single method, or split out.

Most test frameworks have some extension point for you to be able to accomplish both of these patterns. Unfortunately, none of them are very flexible. In my tests, I want to have complete control over lifecycle, as my tests become more complicated to set up. My ideal would be to author tests as I do everything else:

  • Method arguments for variation in a single isolated test
  • Constructor arguments for delivering fixtures for multiple tests

Since I’m using Fixie, I can teach Fixie how to recognize these two types of tests and build individual test plans for both kinds. We could be silly and cheat with things like attributes, but I think we can be smarter, right? Looking at our two test types, we have two kinds of test classes:

  • No-arg constructor, methods have arguments for context/fixtures
  • Constructor with arguments, methods have no arguments (shared fixture)

With Fixie, I can easily distinguish between the two kinds of tests. I could do other things, like key off of namespaces (put all fast tests in one folder, slow tests in another), or separate by assemblies, it’s all up to me.

But what should supply my fixtures? With most other test frameworks, the fixtures need to be plain – class with a no-arg constructor or similar. I don’t want that. I want to use a library in which I can control and build out my fixtures in a deterministic, flexible manner.

Enter AutoFixture!

I’ll teach Fixie how to run my tests, and I’ll teach AutoFixture how to build out those constructor arguments. AutoFixture is my “Arrange”, my code is the Act, and for assertions, I’ll use Shoudly (this one I don’t care as much about, just should-based is enough).

First, let’s look at the simple kinds of tests – ones where the test is completely encapsulated in a single method.

Testcase Class per Class

For TestClass Per Class, my Fixie convention is:

public class TestcaseClassPerClassConvention : Convention
{
    public TestcaseClassPerClassConvention()
    {
        Classes
            .NameEndsWith("Tests")
            .Where(t => 
                t.GetConstructors()
                .All(ci => ci.GetParameters().Length == 0)
            );

        Methods.Where(mi => mi.IsPublic && mi.IsVoid());

        Parameters.Add(FillFromFixture);
    }

    private IEnumerable<object[]> FillFromFixture(MethodInfo method)
    {
        var fixture = new Fixture();

        yield return GetParameterData(method.GetParameters(), fixture);
    }

    private object[] GetParameterData(ParameterInfo[] parameters, Fixture fixture)
    {
        return parameters
            .Select(p => new SpecimenContext(fixture).Resolve(p.ParameterType))
            .ToArray();
    }
}

First, I need to tell Fixie what to look for in terms of test classes. I could have gone a lot of routes here like existing test frameworks “Things with a class attribute” or “Things with methods that have an attribute” or a base class or a namespace. To keep things simple, I look for classes named “Tests”. Next, because I want to target a workflow where AAA is in a single method, I make sure that this class has only no-arg constructors.

For test methods, that’s a bit easy – I just want public void methods. No attributes.

Finally, I want to fill parameters from AutoFixture. I tell Fixie to add parameters from AutoFixture, resolving each parameter value one at a time from AutoFixture.

For now, I’ll leave the AutoFixture configuration alone, but we’ll soon be layering on more behaviors as we go.

With this in place, my test becomes:

public class CalculatorTests
{
    public void ShouldAdd(Calculator calculator)
    {
        calculator.Add(2, 3).ShouldBe(5);
    }

    public void ShouldSubtract(Calculator calculator)
    {
        calculator.Subtract(5, 3).ShouldBe(2);
    }
}

So far so good! Now let’s look at our Testcase Class per Fixture example.

Testcase Class per Fixture

When we want to have a single arrange/act, but multiple assertions, our test lifecycle changes. We now want to not have to re-run the Arrange/Act every single time, we only want it run once and then each Assert work off of the results of the Act. This means that with our test class, we want it only run/instantiated once, and then the asserts happen. This is different than parameterized test methods, where we want the fixture recreated with every test.

Our Fixie configuration changes slightly:

public class TestcaseClassPerFixtureConvention : Convention
{
    public TestcaseClassPerFixtureConvention()
    {
        Classes
            .NameEndsWith("Tests")
            .Where(t => 
                t.GetConstructors().Count() == 1
                && t.GetConstructors().Count(ci => ci.GetParameters().Length > 0) == 1
            );

        Methods.Where(mi => mi.IsPublic && mi.IsVoid());

        ClassExecution
            .CreateInstancePerClass()
            .UsingFactory(CreateFromFixture);
    }

    private object CreateFromFixture(Type type)
    {
        var fixture = new Fixture();

        return new SpecimenContext(fixture).Resolve(type);
    }
}

With Fixie, I can create as many configurations as I like for different kinds of tests. Fixie layers them on each other, and I can customize styles appropriately. If I’m migrating from an existing testing platform, I could even configure Fixie to run the existing attribute-based tests!

In the configuration above, I’m looking for test classes ending with “Tests”, but also having a single constructor that has arguments. I don’t know what to do with classes with multiple constructors, so I’ll just ignore those for now.

The test methods I’m looking for are the same – except now I’ll not configure any method parameters. It would be weird to combine constructor arguments with method parameters for this style of test, so I’m ignoring that for now.

Finally, I configure test execution to create a single instance per class, using AutoFixture as my test case factory. This is the piece that starts to separate Fixie from other frameworks – you can completely customize how you want your tests to run and execute. Opinionated frameworks are great – but if I disagree, I’m left to migrate tests. Not a fun proposition.

A test that uses this convention becomes:

public class InvoiceApprovalTests
{
    private readonly Invoice _invoice;

    public InvoiceApprovalTests(Invoice invoice)
    {
        _invoice = invoice;

        _invoice.Approve();
    }

    public void ShouldMarkInvoiceApproved()
    {
        _invoice.IsApproved.ShouldBe(true);
    }

    public void ShouldMarkInvoiceLocked()
    {
        _invoice.IsLocked.ShouldBe(true);
    }
}

The constructor is invoked by AutoFixture, filling in the parameters as needed. The Act, inside the constructor, is executed once. Finally, I make individual assertions on the result of the Act.

With this style, I can build up a context and incrementally add behavior via assertions. This is a fantastic approach for lightweight BDD, since I’m focusing on behaviors and adding them one at a time.

Next up, we’ll look at going one step further and integrating the database into our tests and using Fixie to wrap interesting behaviors around them.

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

Categories: Blogs

Implementing Agile in Large Enterprises

TV Agile - Thu, 02/05/2015 - 18:19
David Brown, IT Director, shares about his experiences with implementing agile in large enterprises and how Agile Open is a great place to learn, grow, and contribute, as well as overcoming reluctance to speak as he moved into leadership. Video producer: http://agileopencalifornia.com/
Categories: Blogs

Culture is the Core of Your Organization

Agilitrix - Michael Sahota - Thu, 02/05/2015 - 15:29

Culture is at the core of your organization. Everything in your organization informs culture. And vice-versa: culture informs everything in your organization. Here is an illustration:

 Structure, Systems, Management, Leadership

Culture is at the Core

Culture = “How we do things around here to succeed”

Each element is the above diagram intimately tied to your organizational culture. Let’s consider each in turn:

  • Leadership: Who is allowed to lead change in your organization? Is it just managers or is anyone allowed to initiate a change program?
  • Management: What are managers expected to do? How are they expected to behave? Are they elected by staff?
  • Org Structure: Is there a hierarchy that shows importance and power?
  • Roles: Do people have clearly defined roles that limit how they can contribute? Can people easily create new roles to meet new business needs?
  • Systems: Are these chosen to serve business needs or to reduce costs and standardize? How do they enforce or limit behaviours?
  • Policies: What rules do we have for people? How much do we trust them to make good decisions on their own?
  • Processes: Are our processes designed to support the needs of customers and staff? How much process (rules) do we need? In what areas?
  • Unwritten rules & norms: What are the sacred cows and taboo subjects? What is acceptable behaviour?
  • Identity: How do we see ourselves in relation to the organization’s purpose?
  • Values: What are the stated values? How well does this reflect what actually happens?
  • Behaviour: What we say and do is the most concrete manifestation of culture. How we think about ourselves and our organizations will show up in every single meeting. Not only in how it is conducted, but in what is noticed and what people choose to say (or more importantly not say).

The arrows linking the elements illustrate that they are all inter-related and connected. It is a web of cross-linking and supporting elements. The web they weave together defines the organizational culture.

Note that the above diagram is illustrative rather than an exhaustive list. For example, we may note that elements such as office structure could be added.

Laloux Holistic Culture Model

The Laloux Culture Model provides a holistic view of culture that encompasses all of the elements shown above (and more!). In his book, Reinventing Organizations, Laloux makes a clear link between these elements is shown. We cannot shift behaviours without shifting the systems we use. This link was also noted in a 2003 journal paper: Systems and Culture: Connecting the Dots.

In contrast, many models of Culture only use some of these elements. For example, the Schneider Culture Model uses a very specific set of filters that examine what is valued by an organization. This is great for building awareness and starting a discussion around culture, but not as useful for identifying a holistic plan for changing it.

 

Changing Culture

Effective and lasting culture change requires that all of these elements shift together. Teaching people new behaviours or beliefs – such as collaborative meeting techniques or how to assume responsibility – will not work in isolation. Neither will changing our systems and processes without other changes. For more on culture change, please see Culture Change: Reinventing Organizations.

Introducing change efforts such as Agile with teams without changing all the organizational elements around it will generally fail to achieve the desired results. Whole Agile is one of several models to propose a holistic change model.

 

 

The post Culture is the Core of Your Organization appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Culture Change: Reinventing Organizations The following infographic adapted from Frederic Laloux’s Reinventing Organizations shows:...
  2. Laloux Culture Model Looking for a way to help evolve your organization’s culture? Frederic...
  3. Whole Agile – Unleash People & Organizations Agile is incomplete. We need to augment it to create...

YARPP powered by AdBistroPowered by

Categories: Blogs

What Model Do Your Estimates Follow?

Johanna Rothman - Wed, 02/04/2015 - 14:50

Cone of UncertaintyFor years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under.

Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.)

This is a Gaussian (normal) distribution. It’s what we expect. But, it’s almost never right. As Laurent says,

“Many projects stay in 90% done for a long time.”

What curve do our estimates follow if they don’t follow a Gaussian distribution?

Troy Magennis, in “The Economic Impact of Software Development Process Choice – Cycle Time Analysis and Monte Carlo Simulation Results,” suggests we should look at the Power-Law (Weibull) distribution.

What this distribution says with respect to estimation is this: We are good at estimating small things. We get much worse with our estimation quickly, and for the long tail  (larger and larger chunks of work), we are quite bad.

Why? Because creating software is innovation. Building software is about learning. We better our learning as we proceed, assuming we finish features.

We rarely, if ever, do the same thing again. We can’t apply precise estimation approaches to something we don’t know.

You should read Troy’s paper because it’s fascinating. It’s well-written, so don’t worry about not being able to understand it. You will understand it. It’s only 10 pages long.

The question is this: What effect does understanding an estimation model have on our estimates?

If we know that the normal distribution is wrong, then we won’t apply it. Right, why would you do something you know to be wrong? You would not estimate large chunks and expect to have a +/- 10% estimate. It doesn’t make sense to do that.

But what can we do? On the printed paper, what the proceedings will show p. 5061, Troy has a table that is telling. In it, he says that if you have large unique work items or you have large WIP, you will have poor predictability. (He has suggestions for what to do for your process.)

My suggestions for your estimation:

  1. Estimate small chunks of work that a team can complete in a day or so.
  2. Keep WIP low.
  3. Replan as you finish work.
  4. Watch your cycle time.
  5. No multitasking.

What should you do when people ask you for estimates? What kind of requirements do you have? If you have large requirements, follow my advice and use the percentage confidence, as in We Need Planning; Do We Need Estimation? Read the estimation series or get Essays on Estimation.

You can predict a little for estimates. You can better your prediction. And, you may have to predict a large effort. In that case, it helps to know what distribution model might reflect your estimate.

Categories: Blogs

yes, your code is opinionated

Derick Bailey - new ThoughtStream - Wed, 02/04/2015 - 13:00

In the last few years, there has been a growing debate (argument) between two ideologies in software design: opinionated vs un-opinionated code. Generally, this argument divides along the lines of people that want an all-in-one framework (opinionated) vs those that want a do-it-yourself approach with smaller libraries (un-opinionated).

Personally, I sit on the small-library side of the fence. But more and more, I have a growing problem with the way libraries are presented to the public as “un-opinionated”.

opinionated

MarionetteJS: A Highly Opinionated BackboneJS Framework

I recently heard someone saying that MarionetteJS is an un-opinionated framework.

I don’t believe this is true.

As the creator and original curator of MarionetteJS, I certainly did build my own opinions in to this library of tools to sit on top of Backbone. Yes, I did borrow some of these opinions from Backbone, directly. I intentionally wrote Marionette as a library of parts that can be used independently, or together to create something more. That philosophy and opinion came directly from Backbone. But beyond Backbone, I built my own opinions based on my own experience in to MarionetteJS.

I know some people are going to say that Backbone and Marionette are un-opinionated about architecture, and that I’m misunderstanding the point of calling them un-opinionated. I disagree with that conclusion.

I believe that both MarionetteJS and BackboneJS are very strongly opinionated about architecture and application level concerns. They both very clearly say architecture should not be dictated by a framework, but should be grown organically, as-needed.

If that’s not an opinion, I don’t know what is.

Marionette, Backbone, Underscore, jQuery – all of the little libraries that you are using on a daily basis, are all very opinionated. These are all flexible, bendable and reconfigurable tools. But that flexibility should not be confused with a lack of opinion. And yes, what these tools are opinionated about may vary, but none of them are un-opinionated.

Code Is Opinion

The core of my problem with “un-opinionated” as a label for any code, is the fallacy it spreads.

Whether or not you realize it, every line of code that you write has an opinion that has helped shape that line of code. The code is not only shaped by that opinion, but is an expression of that opinion.

It is your opinion that the variable should be named that. It is your opinion that the method should take these parameters, in this order. It is your opinion that the object should contain these methods, and perform this behavior. It is your opinion that the public API for this module should expose these methods and interfaces. The variable names, the method name, the object names, the types, the modules, the public API – all of it, from the smallest bits out to the code that other developers interact with – it is all laced with opinion.

Even if you are deferring your opinion to the style guide, guidance, or input of other developers, it is still the opinion of someone.

Making Implicit Opinions Explicit

It is our job as developers, to consider the next person that will deal with the code we are writing. Whether that person is on our team, is someone using an open source library, or is our own self in the near to distant future, making implicit opinions know is a very important task.

The best way that I’ve found to make these opinions known, is through documentation and examples. But I don’t mean API documentation alone. Rather, I mean a higher level of documentation and example, where the various parts of what we are building are put together for other people to see.

Write “Getting Started” guides and “How To” articles. Record screencasts of how you are using the various pieces together. Talk to other people and show them what you are doing so that they can help you with this.  Find ways in which you can make your implicit opinions known. Make them explicit so that the developers who follow behind you will be able to understand not only your implementation, but also your intention.

Examining Your Own Opinions

The ability to make an implicit knowledge and opinions known requires the ability to examine to core of your own opinions and beliefs. Why do you believe that code should look that way? What experience and influence is hiding in that decision? Is that experience really going to apply here? Will that influence be left unchecked, or has it been thoroughly vetted to ensure it is valid here?

Making our own knowledge explicit is difficult, at best, because it can open us up to the possibility that we are wrong. No one wants to be wrong, even if we know we are. There can be pain and vulnerability in admitting that your opinion is based on incorrect or misapplied ideas. If you’re able to do this, though, the opinions that you espouse will have that much more power and weight, as they will have been tested against the opinions and experiences of others.

That doesn’t mean your opinions won’t change. They probably will, to be honest. But we have to be open to that possibility if we want our opinions to have any amount of influence.

For Others. For Ourselves.

The next time you find yourself thinking about your own code, stop for a moment and think about the implicit opinions you are stating in the code. Is there something that you are assuming in the way it will be used? Would the team you’re working with benefit from those opinions being made explicit? Would *you* benefit from this, in the future?

Making our own opinions known can be a critical part in the success of anything that we do, whether it is for the benefit of others, or for ourselves.

– Derick

 

Categories: Blogs

Thoughts on OOP2015

thekua.com@work - Wed, 02/04/2015 - 11:15

I spent the first half of last week in Munich, where I was speaking at OOP Conference 2015. I missed last year when Martin Fowler was a keynote but had presented both in 2013 and 2012.

The conference still seems to attract more seasoned people like architects and decision makers and I am still constantly surprised at the number of suits I see for a technical conference – I do not know if that is more of a German culture difference as well. I felt like there were significantly more German-speaking sessions than English ones, and I sat in a number of them when I expanded my vocabulary.

I was only there for three of the five days of the conference, and was lucky enough to be invited and attend a special dinner on Monday evening where Dr Reinhold Ewald (a former German astronaut) gave a presentation about what it was like being an astronaut, what they do in space and some of the interesting challenges.

I saw a number of the keynotes and talks which I’ll briefly summarise here:

  • Challenges and Opportunities for the Internet of Things (IoT) by Dr Annabel Nickels – A relatively introductory session on what the Internet of Things actually means. The talk explained the IoT well, why it’s not possible and what people are experimenting with. It was clear that security and privacy aspects had not advanced and that there was still a lot of work to go, as there were lots of questions from the audience, but no clear answers in this space – more “it’s something we’re looking into”-sort of answers
  • Coding Culture by Sven Peters – Sven is an entertaining, engaging and obviously well-practiced presenter who knows how to engage with the audience with pictures and stories. His talk focused on coding culture – but more particularly the coding culture of Atlassian, the company Sven works for. An entertaining talk about how they work inside the company, but was not particularly surprising for me since I know already a lot about that company.
  • Aktives Warten für Architekten by Stefan Toth (Actively Waiting for Architecture) – A nice introduction to the Last Responsible Moment or what is more popular in the Agile community these days, Real Options.
  • Ökonomie und Architektur als effektives Duo by Gernot Starke, Michael Mahlberg (Economics and Architecture as an effective pair) – From my understanding, the talk focused on bringing the idea of calculating ROI on an architectural front. The pair spent a lot of ideas introducing financial terms and then a number of spreadsheets with a lot of numbers. Although well-intentioned, I wasn’t sure about the “calculations” they made since a lot of it was based on estimates of “man-days” needed and “man-days” spent/saved – it all looks very good when calculated out, but they didn’t really spent much time eliciting how they get estimates. They spent a lot of time introducing Aim42 which I wasn’t familiar but will now look into.

I ran two talks that had both good attendance and great feedback (like the one below):

OOP2015 - Best Talk

The fist was “The Geek’s Guide to Leading Teams” where I focused on exploring the responsibilities and remits of what a Tech Lead does and how it’s quite different from being a developer.

The Geek's Guide to Leading Teams from Patrick Kua

The second was “Architecting for Continuous Delivery” which focused on the principles and considerations for when people build systems with Continuous Delivery in mind.

Architecting For Continuous Delivery from Patrick Kua

I had a great time visiting the conference and had an interesting time expanding my German vocabulary as I tried to explain what I and what my company do in German – something I didn’t really do a lot of when I was living in Berlin.

Categories: Blogs