Skip to content

Feed aggregator

Generation Y: Wir wollen unser Leben genießen

Scrum 4 You - Thu, 10/16/2014 - 07:56

An vielen Ecken hört man es: die “Generation Y” will anders arbeiten. Die jungen, gut ausgebildeten Menschen zwischen 20 und 30 wollen einfach nicht mehr so hart rackern wie die Generation vor ihnen, heißt es. Und andererseits wissen die Vertreter der “Generation Me” (auch als Baby Boomer bezeichnet) nicht, wie sie im Job mit dieser Generation umgehen sollen. Nähern wir uns dem Thema Work-Life-Balance mit der Brille der “Generation Me”, dann verfällt man schnell der Idee, dass es neben der Arbeit noch etwas anderes geben sollte. Neben der Arbeit. Mich hat diese Trennung von Arbeit und Freitzeit immer gewundert. So als hätte man zwei Leben, als könne man jede Minute zweimal ausgeben: privat und beruflich.

Generation Me: erfolgreich krank

Woher kommt das Bedürfnis bei Menschen der Generation, der auch ich angehöre, nach dieser Work-Life-Balance? Vielleicht weil wir den Wohlstand, das zweite und das dritte Auto, damit erkauft haben. Wir haben sehr viel und sehr hart gearbeitet, denn harte Arbeit ist unser Statussymbol. Gleichzeitig haben wir nicht nur finanzielle Erfolge und Wohlstand erarbeitet: viele von uns haben sich im wahrsten Sinne des Wortes krank gearbeitet. Ich gebe es zu, auch ich bin bei zwei bis vier Flügen pro Woche und durch das ständige Schlafen in Hotels nicht so fit und gesund, wie ich es sein könnte. Auch die Zeitungen und Magazine sind voll von Berichten über unsere schwer erarbeiteten Zivilisationskrankheiten. Wäre ich, so wie viele andere, auch mit 30 Vater geworden, wäre meine Tochter oder mein Sohn jetzt schon 15 und würde sich zu Recht fragen, ob dieses Kaputtarbeiten irgendeinen Sinn hat und ob er oder sie das will. Ihre Antwort wäre natürlich: “Nein!” Und die Vertreter der Generation Y haben natürlich recht, sie müssen es auch gar nicht mehr.

Langweilige Paradiese

Ihre Eltern haben in vielen Unternehmen bereits die vollkommenen Paradiese geschaffen. Dort sind die Arbeitszeiten festgezogen, alles ist geregelt und wer freiwillig mehr leisten will, wird schief angeschaut (natürlich gilt das nicht in jedem Unternehmen). Gleichzeitig wird die Alterspyramide die Gehälter steigen lassen. Bei einer momentanen Geburtenrate von 1,34 in Österreich und der Tatsache, dass die Baby Boomer allmählich in Massen in Rente gehen, wächst der Wert der Arbeitskraft ins Gigantische.
Gleichzeitig sind die großen Betriebe so durchgestylt, dass die Folge nur noch verwöhnte Langeweile sein kann. Wieso ich das sage?

Ein Beispiel: Ich hatte einen Bewerber zum Interviewtermin, der aus der Automobilwirtschaft kommt. Heute 30 Jahre alt, Doktor der Soziologie, entscheidet er sich bewusst gegen die 35-Stunden-Arbeitswoche in einem großen deutschen Automobilkonzern. Die Arbeit dort ist nicht etwa zu anstrengend, sondern zu langweilig. Dort sind die Arbeitsabläufe geklärt, die Projektmanager verbringen ihre Zeit in stundenlangen Meetings, in denen doch nichts Wesentliches passiert, und der Effekt, also ihr Beitrag, ist gleich Null. Die Arbeit wird in Großunternehmen bzw. -konzernen sowieso von Dienstleistern erledigt – wie es Putzerfische bei einem Wal tun. Etwas bewegen, Sinn stiften und sich beweisen, dabei vielleicht auch scheitern und lernen, ist in diesen Unternehmen schwer geworden.

Doch schauen wir mal dorthin, wo die eigentlichen Veränderungen derzeit passieren – nein, nicht bei Goolge und Co. Ganz ehrlich, eine Übermutter als Arbeitgeber, die mit ständig verfügbarem Essen, Massage und 1000 anderen Annehmlichkeiten aufwartet, wo Geld keine Rolle spielt und man machen kann, was man will, erzeugt kein Umfeld, in dem Innovation aufkommen kann. Der Spieltrieb wird angefacht, sicher, und es ist bestimmt ultracool, bei Google zu arbeiten. Aber mal ehrlich, welche Innovationen kamen von Google? Eine einzige! Ihre geniale Suche. Alles andere ist nachgebaut und bestenfalls optimiert. Google geht gerade den Weg der meisten großen Unternehmen: die Kreativität ist dahin, man beginnt, die Konkurrenz und die neuen Ideen zuzukaufen, statt selbst tolle Dinge zu machen.

Neuer Realismus in der Arbeitswelt

Wo ist also das Neue für die Arbeitswelt? Es beginnt immer am Rand. Da ist etwas Neues zu beobachten. Wahrscheinlich werden jetzt viele Trendforscher sagen: “alter Kaffee”, aber ich nehme gerade etwas vollkommen Neues wahr. Kleine Firmen, die weltweit verteilt sind und dank neuer Kommunikations- und Arbeitsinfrastrukturen wie Google Hangout, Skype und GitHub Bedingungen geschaffen haben, mit denen man als kleines Team weltweit miteinander arbeiten kann, beginnen tatsächlich ganz anders zu arbeiten.
Da erzählen dann diese merkwürdigen Menschen aus der Generation Y, dass sie zuhause in ihren Wohnzimmern oder kleinen Arbeitszimmern sitzen, und gleichzeitig bei ihrer Familie sein können (Beispiele für diese Firmen sind: WordPress.com oder Bufferapp). Die Firmenmitglieder treffen sich ab und zu, um sich auch mal zu sehen, aber die Arbeit wird remote, verteilt und dezentralisiert gesteuert. Es entstehen dabei sogar neue Taskmanagement-Systeme, die tatsächlich ein neues Konzept verfolgen: IDoneThis. Sie zeigen, was gelungen ist, und nicht das, was man hätte tun sollen. Das ist eines der ersten Systeme, das mit einer vollkommen anderen Sicht entwickelt wurde. Hier ist es nicht vorgesehen, jemand anderem zu sagen, was er zu tun hat. Jeder sagt – offen – etwas darüber, was er getan hat. Ziemlich verrückt aus der Sicht der Generation ME. Work-Life-Balance spielt für die Generation Y keine Rolle mehr. Sie haben schon lange einen Weg gefunden, freier und viel realistischer mit ihrem Leben umzugehen.

Related posts:

  1. Vacation is over – Vacation starts
  2. Prioritäten | Product Owners Tools
  3. Toyota Production System (4)

Categories: Blogs

Building Better Business Cases for Digital Initiatives

J.D. Meier's Blog - Wed, 10/15/2014 - 19:26

It’s hard to drive digital initiatives and business transformation if you can’t create the business case.  Stakeholder want to know what their investment is supposed to get them

One of the simplest ways to think about business cases is to think in terms of stakeholders, benefits, KPIs, costs, and risks over time frames.

While that’s the basic frame, there’s a bit of art and science when it comes to building effective business cases, especially when it involves transformational change.

Lucky for us, in the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned in building better business cases for digital initiatives.

What I like about their guidance is that it matches my experience

Link Operational Changes to Tangible Business Benefits

The more you can link your roadmap to benefits that people care about and can measure, the better off you are.

Via Leading Digital:

“You need initiative-based business cases that establish a clear link from the operational changes in your roadmap to tangible business benefits.  You will need to involve employees on the front lines to help validate how operational changes will contribute to strategic goals.”

Work Out the Costs, the Benefits, and the Timing of Return

On a good note, the same building blocks that apply to any business case, apply to digital initiatives.

Via Leading Digital:

“The basic building blocks of a business case for digital initiatives are the same as for any business case.  Your team needs to work out the costs, the benefits, and the timing of the return.  But digital transformation is still uncharted territory.  The cost side of the equation is easier, but benefits can be difficult to quantify, even when, intuitively, they seem crystal clear.”

Start with What You Know

Building a business case is an art and a science.   To avoid getting lost in analysis paralysis, start with what you know.

Via Leading Digital:

“Building a business case for digital initiatives is both an art an a science.  With so many unknowns, you'll need to take a pragmatic approach to investments in light of what you know and what you don't know.

Start with what you know, where you have most of the information you need to support a robust cost-benefit analysis.  A few lessons learned from our Digital Masters can be useful.”

Don’t Build Your Business Case as a Series of Technology Investments

If you only consider the technology part of the story, you’ll miss the bigger picture.  Digital initiatives involves organizational change management as well as process change.  A digital initiative is really a change in terms of people, process, and technology, and adoption is a big deal.

Via Leading Digital:

“Don't build your business case as a series of technology investments.  You will miss a big part of the costs.  Cost the adoption efforts--digital skill building, organizational change, communication, and training--as well as the deployment of the technology.  You won't realize the full benefits--or possibly any benefits--without them.”

Frame the Benefits in Terms of Business Outcomes

If you don’t work backwards from the end-in-mind, you might not get there.  You need clarity on the business outcomes so that you can chunk up the right path to get there, while flowing continuous value along the way.

Via Leading Digital:

“Frame the benefits in terms of the business outcomes you want to reach.  These outcomes can be the achievement of goals or the fixing of problems--that is, outcomes that drive more customer value, higher revenue, or a better cost position.  Then define the tangible business impact and work backward into the levers and metrics that will indicate what 'good' looks like.  For instance, if one of your investments is supposed to increase digital customer engagement, your outcome might be increasing engagement-to-sales conversation.  Then work back into the main metrics that drive this outcome, for example, visits, like inquiries, ratings, reorders, and the like.

When the business impact5 of an initiative is not totally clear, look at companies that have already made similar investments.  Your technology vendors can also be a rich, if somewhat biased, source of business cases for some digital investments.”

Run Small Pilots, Evaluate Results, and Refine Your Approach

To reduce risk, start with pilots to live and learn.   This will help you make informed decisions as part of your business case development.

Via Leading Digital:

“But, whatever you do, some digital investment cases will be trickier to justify, be they investments in emerging technologies or cutting-edge practices.  For example, what is the value of gamifying your brand's social communities?  For these types of investment opportunities, experiment with a test-and-learn approach.  State your measures of success, run small pilots, evaluate results, and refine your approach.  Several useful tools and methods exist, such as hypothesis-driven experiments with control groups, or A/B testing.  The successes (and failures) of small experiments can then become the benefits rationale to invest at greater scale.  Whatever the method, use an analytical approach; the quality of your estimated return depends on it.

Translating your vision into strategic goals and building an actionable roadmap is the firs step in focusing your investment.  It will galvanize the organization into action.  But if you needed to be an architect to develop your vision, you need to be a plumber to develop your roadmap.  Be prepared to get your hands dirty.”

While practice makes perfect, business cases aren’t about perfect.  Their job is to help you get the right investment from stakeholders so you can work on the right things, at the right time, to make the right impact.

You Might Also Like

Cloud Changes the Game from Deployment to Adoption

How Digital is Changing Physical Experiences

McKinsey on Unleashing the Value of Big Data Analytics

Categories: Blogs

Podcast with Cesar Abeid Posted

Johanna Rothman - Wed, 10/15/2014 - 16:42

Cesar Abeid interviewed me, Project Management for You with Johanna Rothman. We talked about my tools for project management, whether you are managing a project for yourself or managing projects for others.

We talked about how to use timeboxes in the large and small, project charters, influence, servant leadership, a whole ton of topics.

I hope you listen. Also, check out Cesar’s kickstarter campaign, Project Management for You.

Categories: Blogs

Scaled Agile Framework: I Learned about ROAM

Learn more about our Scrum and Agile training sessions on WorldMindware.com

The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM.  The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning.  ROAM stands for Resolved, Owned, Accepted, Mitigated.  The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them.  These risks are then place on a visible grid that has each of the four categories marked.  In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning.  Cool!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Today about Iteration big and small

tinyPM Team Blog - Wed, 10/15/2014 - 12:49

We have already had User Story as most popular tool. But this is not the end. Today about Iterations: the small and big ones, these that are completed and those that are never stopped.

Yes We Can

Iteration is a period of 1 to 4 weeks. During this time Customer needs to decide what is the most important at this moment. 4 weeks is also called the Sprint but we prefer Iteration as it’s stronger option.

Iteration is not only about programming but also about tests and more. Actually tests are run before the programming phase.

We also have to mention about infinite period. In this case Iteration is one, only User Story has to be completed in some period of time and then disappears. In this place another User Story appears. Customer tells about that User Story and if it’s good we start with the new one.

And what do you think about this?

Categories: Companies

News update 2014/10 – Why Coaching is Important

ScrumSense.com - Peter Hundermark - Wed, 10/15/2014 - 10:49

Coaching can make the difference between an organisation’s success or failure. In this month’s blog, Peter Hundermark outlines why effective coaching allows companies to admit their weaknesses and move towards a happier and more effective workplace. Read the full article here.

Kanban PrinciplesKanban Training We have FOUR seats remaining on the upcoming Applying Kanban (Foundation) course taking place on the 20-21 Oct 2014 in Sandton. Be sure to book your place before these are snapped up. Should these dates not work for you, we will be running the course again on the 04-05 May 2015.

 

We also still have a few spaces available on our upcoming Improving & Scaling Kanban (Advanced) course which will be taking place in Sandton on the 23-24 Oct 2014. We are running a 3-for-2 special offer on both the certified Foundation and Advanced courses, so be sure to secure your place!

 

Interesting Links

InfoQ Publications

InfoQ have published the remaining two articles in the series from the short book “Leading Self-Organising Teams” written by Dr. Sigi Kaltenecker & Peter Hundermark. Have a read of these articles: “why do we need self-organising teams?” and “what is Leading Self-Organising Teams all about?

Q&A Teleconferences

Esther Derby is offering free Q&A teleconferencing sessions. Each month Esther chooses a topic which will be of interest to people who coach, manage, or work on software teams. Follow this link to sign up. Upcoming Courses Applying Kanban (Foundation) – (JHB) – Only 4 seats left!
20-21 Oct 2014
FNB Conference & Learning Centre, Sandton

 

Improving & Scaling Kanban (Advanced) – (JHB)
23-24 Oct 2014
FNB Conference & Learning Centre, Sandton

 

Certified Scrum Product Owner (JHB) – Fully booked!
04 – 05 Nov 2014
FNB Conference & Learning Centre, Sandton

 

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

 

Course schedule and Book Online

The post News update 2014/10 – Why Coaching is Important appeared first on ScrumSense.

Categories: Blogs

Continuous Improvement vs. Continuous Change

Agile Tools - Wed, 10/15/2014 - 08:29

Evolution-des-wissens

I’m a little down on the notion of continuous improvement these days. It’s not that it doesn’t happen – it does…sometimes. I simply fear that it promises too much. I think part of it is the terminology. You see in the real world continuous improvement is neither truly continuous or necessarily an improvement.

To begin with, I’ve critiqued the notion of continuously improving before from the point of view that keeping any process happening full time is ludicrous. Certainly once every sprint is nowhere near continuous. I guess maybe it is continuous when you compare it to other more plan driven methods, but that’s far from continuous in my book.

No, the part that I find most objectionable is the improving part. You see, it’s misleading. It suggests to me that every change is an improvement. That every effort is a step forward, not back. And that is simply not how it works. It would be better labelled periodic experimentation, or punctuated mutation. You see, in the real world, when we change something, we never really know if it’s going to work out or not. There are 50/50 odds that the change will actually make things worse! 

Of course that’s a good thing. We learn a little either way. Hopefully.

The problem I have with continuous improvement is that it sets up an unreasonable expectation in those we sell it to. To restate the sales pitch: every change will be an improvement and they happen all the time.

If every change were really an improvement, I would be worried that I had been transported to an alternative universe. That I was being monitored by aliens. That there was a black helicopter hovering over my house. I’d be making a tin foil bunny suit. Fortunately I know what universe I’m in, that there aren’t any black helicopters over my house, and tin foil tends to chafe in the damnedest places. Not too sure about the aliens…

Fortunately, many of my efforts at improvement fail. And that’s the way it should be.


Filed under: Agile, Process Tagged: continuous, evolution, experimentation, failure, improvement
Categories: Blogs

SAFe for Lean Systems Engineering (SAFe LSE) News Update

Agile Product Owner - Tue, 10/14/2014 - 23:30

We’ve been working diligently on continued conceptualization of the SAFe LSE Big Picture, as well as the new article content. To that end, we’ve just updated the Big Picture to rev 0.30. (yeah, 30 revs so far, see below).

Big Picture for SAFe Lean Systems Engineering v0.30.

Big Picture for SAFe Lean Systems Engineering v0.30.

In addition, we just announced the first training course for SAFe LSE. Leading SAFe LSE is a three-day course, the first of which which will be offered in Boulder, February 3-5, 2015. Registration is now open here.  Harry Koehnemann, Alex Yakyma and I will be teaching that course, so you can hear the new content “right from the horses” mouths.

With respect to the new framework, our current target is to publish the website as a work-in-process towards the end of this year (likely end of November), with a full release, including an exam and Certification process, later in 2015.

Categories: Blogs

7 Best Practices for Facilitating Scrum Retrospectives

Scrum Expert - Tue, 10/14/2014 - 20:29
Improvement is one of the core principle of the Agile Manifesto that states “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Retrospectives are a powerful technique to achieve this goal in Scrum and in this blog post, Jonathan Berger proposes seven practices to facilitate retrospectives. Facilitating a retrospective is not easy and this role is described as being a mix between a courthouse judge and a stenographer. Based on his experience, Jonathan Berger discusses some patterns that can make the ...
Categories: Communities

AgileByExample, Warsaw, Poland, October 29-31, 2014

Scrum Expert - Tue, 10/14/2014 - 18:22
AgileByExample is a Lean and Agile conference taking place in Warsaw, Poland that helps you learn Agile on live examples. The last day is dedicated to a Lean Agile Dojo. Keynotes, talks and discussions are all in English. In the agenda of AgileByExample you can find topics like “Beyond Metrics”, “#NoEstimates – Alternatives to Estimates”, “Performance Appraisals are incompatible with Agile Mindset”, “What could you do with 10 years of Continuous Improvement?”, “Creeping Agile – changing the flock one sheep at a time”, “7 pitfalls that can destroy new Product Owners ...
Categories: Communities

Why Coaching is Important

ScrumSense.com - Peter Hundermark - Tue, 10/14/2014 - 16:16
What is the Problem?

For people in 20th century organisations training was an obvious necessity. Just look at the still-classical organisation and see that it has a Training Department neatly tucked into the organisation chart just under Human Resources. (I hate that name…but I digress.)

Much changes in our post-industrial world where we think for a living, solving increasingly complex problems. Our paradigm for helping people be effective has not yet caught up.

What are the challenges?

  • We are solving hard problems. This requires the brains of multiple people to be aligned and work collectively to emerge solution options.
  • Failure remains stigmatised as something bad, rather than being recognised as an essential and desirable outcome of experimentation towards innovation.
  • We remain stuck in authoritative command-and-control cultures that fail to unlock the potential of people.
  • Employees acknowledge their own individual achievements, but less so their contribution to the result of a shared effort.
  • Managers have not yet grasped their new role as enablers rather than directors.
  • Most organisations reward individualism while hoping for teamwork.
  • …add yours here…
What is Coaching?

Professional coaching may be described as a method for helping a person or a team to achieve specific goals in their professional lives. Paraphrasing Kaltenecker and Myllerup: the coach acknowledges that the person or team being coached already has the potential abilities required for reaching the goals and the assignment for the coach is to help unlock this hidden potential.

An “agile coach” often steps into acting as a teacher, advisor, mentor or role model. Here she applies her own expertise to lead and guide the individual or team in specific ways. Yet as soon as possible she should return to a coaching stance to return appropriate the power balance to the relationship.

The diagram depicts the difference between when the “agile” coach is relying on her own expertise of the content as distinct from the systemic coach using her own ignorance of the full organisational context and applying curiosity as a powerful helping tool to build relationship.

Agile vs Systemic Coaching

Why Do We Need Coaching?

Ask any successful leader and she will tell you stories about the people who have helped her, formally and informally, along her journey.

In order to learn and grow we require honest feedback. Without enough trust, honest feedback is unlikely to be offered and received in a productive manner. Traditional work environments do not provide safety for trust to flourish.

And in the modern work context that requires collaboration to produce good results we need to develop new “soft” skills that we were not taught at university or technicon. Teams and individuals need to learn to be vulnerable to one another.

However it is not a given that we will ask for help. There are hard questions to answer, for example:

  • How do I recognise when I or my team needs help? Am I even capable of knowing what it is I don’t know (my blind spots)?
  • Why would my boss pay me a salary when I need outside help to do my job?
  • How does asking for help make me feel? I have to “lose face” to accept help from another.
  • …add your own…

In the South African cultural context where “cowboys don’t cry” and “boer maak ’n plan” it can be particularly hard to ask for help. And in the “controlling” and “competitive” styles of organisational cultures that still predominate worldwide it can be seen as a sign of weakness.

So many of us live with an unhealthy tension between needing help from others in order to grow, and the uncertainty about whether or when it’s okay to ask.

The coach as trusted external party is well-skilled and well-placed to facilitate the necessary conversations to help teams grow trust, deal with conflict and offer commitment that in turn lead to increased accountability and improved outcomes.

An Economic View

In work over nine years with more than 100 teams we have observed a marked difference between the extent and the pace of growth of individuals and teams that have received coaching and those who have “gone it alone” after, perhaps, a two-day training class.

An analysis of our own data shows a correlation between “performing” teams and the quantum of help. The sweet spot seems to be between one and two days of coaching per team member during the first year of transition. To be clear this includes all facets such as advising and organisational development. Our data does differentiate between individual and team coaching, yet clearly there is a need for both.

Benefits we have observed during and after coaching include:

  • Happier and more engaged team members
  • Reduced staff turnover
  • An increased sense of “we”
  • An increase in self-confidence and independence
  • Increases customer and stakeholder satisfaction through value delivery
  • Increased throughput and decreased “time to market”
  • Increased transparency and predictability

When asked how soon the benefits exceeded the costs, many clients have experienced improvement within a few weeks and the classic “J-curve” of change has not been felt. And it is not uncommon to hear “we have doubled/halved X compared with last quarter/year”.

Adding Perspective

Before we conclude that coaching is some “magic elixir”, let’s be clear that contexts differ and it is hard to attribute causality to a single element. Nevertheless we have many times heard “we should have got coaching earlier and had more of it”.

As Weick and Sutcliffe remind us in their excellent book about High Reliability Organisations, it is “a sign of strength to know when you’ve reached the limits of your knowledge and know enough to ask for help”.
¹Sigi Kaltenecker (Loop Organisationsberatung) & Bent Myllerup (agile42): Agile & Systemic Coaching
http://www.scrumalliance.org/community/articles/2011/may/agile-systemic-coaching

²Karl Weick and Kathleen Sutcliffe: Managing the Unexpected—Resilient Performance in an Age of Uncertainty (Second Edition, 2007, Wiley), page 80.

The post Why Coaching is Important appeared first on ScrumSense.

Categories: Blogs

Book List for Enterprise Agile Transformations

Learn more about our Scrum and Agile training sessions on WorldMindware.com

Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them.  This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent.  Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.

I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization.  It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile.  It is about urgency and need, and about a recognition that Agile is better than not-Agile.  If you aren’t in that situation, this is not the book list for you.

Culture

These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture.  Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.

The Corporate Culture Survival Guide – Edgar Schein

Beyond the Culture of Contest – Michael Karlburg

The Heart of Change – John Kotter

Management

This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments.  These books all touch on culture in various ways, and build on the ideas in the books about culture.  For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.

Good to Great – Jim Collins

The Leaders’ Guide to Radical Management – Steve Denning

The Mythical Man-Month – Frederick Brooks

Agile at Scale

These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.

Scaling Lean and Agile Development – Bas Vodde, Craig Larman

Scaling Agility – Dean Leffingwell

Lean Software Development – Mary and Tom Poppendieck

Supporting

These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.

Toyota Talent: Developing Your People the Toyota Way – Jeffrey Liker, David Meier

Agile Retrospectives – Esther Derby

Continuous Delivery – Jez Humble, David Farley

The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.

The OpenAgile Primer – Mishkin Berteig, et. al.

Priming Kanban – Jesper Boeg

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Scaling Agile Your Way: How to Develop and Implement Your Custom Approach (Part 4 of 4)

Agile Management Blog - VersionOne - Tue, 10/14/2014 - 14:46

In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives.  Each agile project has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.  In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects:  Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (Tables 1-4 of Part 1).   I also presented a brief overview of various popular agile and lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.

Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS.  SAFe and MAXOS represent radically different approaches to scaling agile. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth.  Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.

In Part 3, I presented the Sweet Spots, Challenge Zones and Unfit zones for SAFe and MAXOS. Figure 1 in Part 3 illustrated the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presented similar information for MAXOS.  The Sweet spot indicates a good match between a scaling agile framework and all scaling agile parameters; consequently the implementation becomes easier, more efficient and effective.  The Challenge Zone indicates a challenging match between a framework and one or more scaling agile parameters, and requires more implementation effort compared to the Sweet Spot.  The Unfit Zone indicates a very poor (almost unworkable) match between a framework and one or more scaling agile parameters.

In Part 3, I explained why it is a good idea to get as close as possible to the sweet spot of your chosen scaling agile framework; it increases the likelihood that your pilot large-scale agile project will have fewer difficulties in succeeding. If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The root cause is likely to be one of these two things:

1.  Internal to your own organization (its history, culture, current practices, etc.).  This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate their understanding and commitment to the success of scaling agile.

2.  Arising from the market and business environment of your organization.  These pressures cannot be removed by senior management (if you want to stay in the business).  You will need to replace or augment some of the scaling agile framework practices with your own custom practices, while retaining the practices from the framework that are still applicable.

The journey from Unfit or Challenge Zone to Sweet Spot is uniquely yours, and cannot be copied from a cookbook.  Over time, you will find that you are moving closer and closer to the Sweet Spot, but may still have a few areas in the Challenge Zone to address.

In this final part of my series, I explain a very important challenge for Scaling Agile Your Way.  It requires each team, program or portfolio to implement one or more key aspects of the chosen framework (whether the key aspect is in the Sweet Spot or Challenge Zone) in unique and customized ways.  I explain how the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be applied to SAFe to make it less prescriptive, “modularize” SAFe, and allow customized implementation of those modules.

The Scrum at Scale framework provides a general language for talking about how to scale Scrum.  At its roots, Scrum is an object-oriented framework.  Each role, artifact and ceremony is defined by the teams’ objectives, participants, inputs and outputs.  Core Scrum allows for many different ways to achieve objectives within given input/output constraints. Modularity allows organizations to establish and improve agile practices incrementally by focusing on one independent module at a time.  Scrum at Scale aspires to develop a “pattern library” of successful approaches that can be used in different contexts; this pattern library is being developed based on a crowd-sourcing approach.

Tables 12-16 in this post (see below) present 10 modules of the Scrum at Scale framework:

1.  Team-Level Scrum Process
2.  Strategic Vision
3.  Backlog Prioritization
4.  Backlog Decomposition and Refinement
5.  Release Planning
6.  Release Management
7.  Feedback
8.  Continuous Improvement and Impediment Removal
9.  Cross-Team Coordination
10. Metrics and Transparency

As the Scrum framework is object-oriented, each of these 10 modules has a set of well-defined goals, inputs and outputs.  It is up to each entity (team or business unit or organization) to implement each module in a way that best suits its own needs and constraints, so long as it produces the desired goals and outputs from a given set of inputs.  The details of implementing each module should be left to each entity, as the implementation details are expected to be different.  Each of Tables 12-16 presents two modules and explains how object-oriented implementation of each module is applicable to SAFe.

SAFe is characterized by its critics as too prescriptive; some of this critique may be fair while other is not.  Critics allege that because SAFe is (overly) prescriptive, it may not work well in many situations.  This prescriptive orientation (real or perceived) of SAFe can be reduced considerably by taking a strong, object-oriented approach in modularizing and implementing SAFe.  Instead of prescribing or specifying how different goals or ceremonies of SAFe should be implemented, why not follow the object-oriented approach of Scrum at Scale framework while implementing SAFe — where each module’s goals, outputs and inputs are emphasized while leaving the implementation details to each entity (team or program or portfolio)?  Of course, constraints arising from inter-team or inter-program coordination and synchronization must be met; even those constraints should be specified in terms of their goals — not by prescribing their implementation details (think of “object-oriented” constraints). 

Table 12:  Modules 1 and 2 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table12

 

Table 13:  Modules 3 and 4 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table13

Table 14:  Modules 5 and 6 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table14

Table 15: Modules 7 and 8 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table15

Table 16: Modules 9 and 10 of Scrum at Scale (Meta)-Framework
and its Application to SAFe

Table16Customization needs and opportunities for the MAXOS framework

These will arise mostly in the context of implementing its advanced engineering practices of:

  • Code contribution
  • Automated testing
  • Continuous integration
  • Feature switches
  • Continuous delivery
  • Collecting and analyzing automated user feedback
  • Making use of cloud computing facilities on a massive scale, etc.

There are open-source and some commercial products available for automated testing, continuous integration and using cloud computing facilities for software development, testing and deployment.  I will not elaborate on MAXOS customization here.

How may an object-oriented implementation of SAFe (applying Scrum at Scale meta-framework guidelines, as explained in this part) suit your organization’s needs and constraints better than following SAFe “by the book?”  Besides the aspects of customization covered in Tables 12-16, are there any other aspects that come to your mind?  I would love to hear from you on these questions or any aspect of this four-part blog series, either here, by email (Satish.Thatte@VersionOne.com), or on
Twitter @smthatte.

Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly

Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS

Part 3: Scaling Agile Your Way:  Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS

Categories: Companies

No More Business as Usual

Rally Agile Blog - Tue, 10/14/2014 - 14:00

When the S&P 500 index was created in 1957, the average expected lifespan of a company on the index was 61 years. By 1980 that lifespan had been cut in half, and in the coming decade it likely will be halved again. What used to be a health index for stable companies is now a thermometer for the fluctuating temperatures of disruptive markets.

The S&P is just one indicator of the evolving environment for businesses. Markets are now global and highly responsive. Competition moves at startup speed. Operational efficiency isn’t a nice-to-have, it’s a necessity. Customers, and their expectations, hold more sway than any executive. And at the heart of all these changes is a technology backbone, accelerating both the opportunities for innovation and the impact of competitive threats.

Adapt or Die

Woolworth’s. Kodak. Blockbuster. Borders. The list of companies that couldn’t survive in this new environment is long and growing.

“Big companies that fail to innovate risk extinction,” says the BBC. “That's the stark truth in the era of 'digital disruption.'"

Being a big fish doesn’t make you immune and being a small fish doesn't make you competitive; disruption will affect nearly every business in some way, it's just a question of how ... and when.

Agility: The Competitive Advantage

What makes some companies survive – and thrive – in this kind of environment, and how can you become one of those companies?

Those that successfully navigate today’s competitive markets know how to sense, create, and respond to change, and they can do it quickly and confidently.

Agility throughout an organization can 'spell the difference between being severely disrupted, or turning the disruption from a threat to a competitive advantage – an opportunity to develop new products, service, markets and business models to help propel the company into the future.'”

These companies don't just practice agile in their software development; they are agile businesses

  • They improve and scale their software development performance so they can deliver more value to customers, faster.
  • They connect their software development performance to business strategy, building flexible portfolio management that adapts quickly to market changes and optimizes for business value.
  • They invest the dividends of their performance gains in market-leading innovation, running experiments and getting fast customer feedback.

Learn how to build agility into your company’s DNA. Download the new Rally Business Agility Survival Guide and get started.

Rally Software
Categories: Companies

Poor Uses for Transparency

Agile Tools - Tue, 10/14/2014 - 08:17

architecture-blue-sky-building-563-825x550

In the Agile world we do a lot of things to try and create transparency within our organizations. We put up information radiators like burn down charts, task boards, and cumulative flow diagrams. We put information up on the walls with sticky notes everywhere you turn. We have team synchronization meetings every day. There’s a lot of information flowing around, so is it even possible that transparency can be misused? Is it possible for transparency to go wrong?

In most cases, I think my default answer to this question would be “no” – in general, I’ll take transparency anytime. However I have run across a few situations with transparency that have made me tear my hair out. There are three different cases that I’m thinking of: Frequency of request, Lack of Decisions, and Missing the point: value.

Updating status information on a regular, even frequent, basis can be useful – especially if the work is high priority. However, there is an upper limit beyond which frequent reporting becomes counter productive. It’s one thing to update status once a week, but when it becomes once a day, something has gone wrong. I’m not really sure that there is a discrete boundary beyond which the reporting becomes too much. All I can say is that you know it when you cross it. The problem is, it ends up creating more churn than productive action.

Transparency isn’t all that useful if it doesn’t lead to meaningful action. A lack of decisions is usually an indicator that there is dysfunction that the transparency is not helping to address. In fact, what you are probably finding is that you are only getting superficial transparency. The question is, why aren’t the decisions getting made?

Finally, transparency is only effective if it helps to understand how the organization delivers value. Often times transparency focuses on things that don’t reflect business value. This is missing the point of transparency. It needs to remain focused on the business value.


Filed under: Agile, Process Tagged: communication, reporting, status, transparency, visibility
Categories: Blogs

AngularJS Training Week

Xebia Blog - Tue, 10/14/2014 - 08:00

Just a few more weeks and it's the AngularJS Training Week at Xebia in Hilversum (The Netherlands). 4 days packed with AngularJS content, from 17 to 20 October, 2014. On these different days we will cover the AngularJS basics, AngularJS advanced topics, Tooling & Scaffolding and Testing with Jasmine, Karma and Protractor.

If you already have some experience or if you are only interested in one or two of the topics, then you can sign up for just the days that are of interest to you.

Visit www.angular-training.com for a full overview of the days and topics or sign up on the Xebia Training website using the links below.

Categories: Companies

5 Decision-Making Strategies that require no estimates

Software Development Today - Vasco Duarte - Tue, 10/14/2014 - 05:00

One of the questions that I and other #NoEstimates proponents hear quite often is: How can we make decisions on what projects we should do next, without considering the estimated time it takes to deliver a set of functionality?

Although this is a valid question, I know there are many alternatives to the assumptions implicit in this question. These alternatives - which I cover in this post - have the side benefit of helping us focus on the most important work to achieve our business goals.

Below I list 5 different decision-making strategies (aka decision making models) that can be applied to our software projects without requiring a long winded, and error prone, estimation process up front.

What do you mean by decision-making strategy?

A decision-making strategy is a model, or an approach that helps you make allocation decisions (where to put more effort, or spend more time and/or money). However I would add one more characteristic: a decision-making strategy that helps you chose which software project to start must help you achieve business goals that you define for your business. More specifically, a decision-making strategy is an approach to making decisions that follows your existing business strategy.

Some possible goals for business strategies might be:

  • Growth: growing the number of customer or users, growing revenues, growing the number of markets served, etc.
  • Market segment focus/entry: entering a new market or increasing your market share in an existing market segment.
  • Profitability: improving or maintaining profitability.
  • Diversification: creating new revenue streams, entering new markets, adding products to the portfolio, etc.

Other types of business goals are possible, and it is also possible to mix several goals in one business strategy.

Different decision-making strategies should be considered for different business goals. The 5 different decision-making strategies listed below include examples of business goals they could help you achieve. But before going further, we must consider one key aspect of decision making: Risk Management.

The two questions that I will consider when defining a decision-making strategy are:

  • 1. How well does this decision proposal help us reach our business goals?
  • 2. Does the risk profile resulting from this decision fit our acceptable risk profile?

Are you taking into account the risks inherent in the decisions made with those frameworks?

All decisions have inherent risks, and we must consider risks before elaborating on the different possible decision-making strategies. If you decide to invest in a new and shiny technology for your product, how will that affect your risk profile?

A different risk profile requires different decisions

Each decision we make has an impact on the following risk dimensions:

  • Failing to meet the market needs (the risk of what).
  • Increasing your technical risks (the risk of how).
  • Contracting or committing to work which you are not able to staff or assign the necessary skills (the risk of who).
  • Deviating from the business goals and strategy of your organization (the risk of why).

The categorization above is not the only possible. However it is very practical, and maps well to decisions regarding which projects to invest in.

There may good reasons to accept increasing your risk exposure in one or more of these categories. This is true if increasing that exposure does not go beyond your acceptable risk profile. For example, you may accept a larger exposure to technical risks (the risk of how), if you believe that the project has a very low risk of missing market needs (the risk of what).

An example would be migrating an existing product to a new technology: you understand the market (the product has been meeting market needs), but you will take a risk with the technology with the aim to meet some other business need.

Aligning decisions with business goals: decision-making strategies

When making decisions regarding what project or work to undertake, we must consider the implications of that work in our business or strategic goals, therefore we must decide on the right decision-making strategy for our company at any time.

Decision-making Strategy 1: Do the most important strategic work first

If you are starting to implement a new strategy, you should allocate enough teams, and resources to the work that helps you validate and fine tune the selected strategy. This might take the form of prioritizing work that helps you enter a new segment, or find a more valuable niche in your current segment, etc. The focus in this decision-making approach is: validating the new strategy. Note that the goal is not "implement new strategy", but rather "validate new strategy". The difference is fundamental: when trying to validate a strategy you will want to create short-term experiments that are designed to validate your decision, instead of planning and executing a large project from start to end. The best way to run your strategy validation work is to the short-term experiments and re-prioritize your backlog of experiments based on the results of each experiment.

Decision-making Strategy 2: Do the highest technical risk work first

When you want to transition to a new architecture or adopt a new technology, you may want to start by doing the work that validates that technical decision. For example, if you are adopting a new technology to help you increase scalability of your platform, you can start by implementing the bottleneck functionality of your platform with the new technology. Then test if the gains in scalability are in line with your needs and/or expectations. Once you prove that the new technology fulfills your scalability needs, you should start to migrate all functionality to the new technology step by step in order of importance. This should be done using short-term implementation cycles that you can easily validate by releasing or testing the new implementation.

Decision-making Strategy 3: Do the easiest work first

Suppose you just expanded your team and want to make sure they get to know each other and learn to work together. This may be due to a strategic decision to start a new site in a new location. Selecting the easiest work first will give the new teams an opportunity to get to know each other, establish the processes they need to be effective, but still deliver concrete, valuable working software in a safe way.

Decision-making Strategy 4: Do the legal requirements first

In medical software there are regulations that must be met. Those regulations affect certain parts of the work/architecture. By delivering those parts first you can start the legal certification for your product before the product is fully implemented, and later - if needed - certify the changes you may still need to make to the original implementation. This allows you to improve significantly the time-to-market for your product. A medical organization that successfully adopted agile, used this project decision-making strategy with a considerable business advantage as they were able to start selling their product many months ahead of the scheduled release. They were able to go to market earlier because they successfully isolated and completed the work necessary to certify the key functionality of their product. Rather then trying to predict how long the whole project would take, they implemented the key legal requirements first, then started to collect feedback about the product from the market - gaining a significant advantage over their direct competitors.

Decision-making Strategy 5: Liability driven investment model

This approach is borrowed from a stock exchange investment strategy that aims to tackle a problem similar to what every bootstrapped business faces: what work should we do now, so that we can fund the business in the near future? In this approach we make decisions with the aim of generating the cash flows needed to fund future liabilities.

These are just 5 possible investment or decision-making strategies that can help you make project decisions, or even business decisions, without having to invest in estimation upfront.

None of these decision-making strategies guarantees success, but then again nothing does except hard work, perseverance and safe experiments!

In the upcoming workshops (Helsinki on Oct 23rd, Stockholm on Oct 30th) that me and Woody Zuill are hosting, we will discuss these and other decision-making strategies that you can take and start applying immediately. We will also discuss how these decision making models are applicable in day to day decisions as much as strategic decisions.

If you want to know more about what we will cover in our world-premiere #NoEstimates workshops don't hesitate to get in touch!

Your ideas about decision-making strategies that do not require estimation

You may have used other decision-making strategies that are not covered here. Please share your stories and experiences below so that we can start collecting ideas on how to make good decisions without the need to invest time and money into a wasteful process like estimation.

Categories: Blogs

The Hard Thing About Hard Things – Ben Horowitz: Book Review

Mark Needham - Tue, 10/14/2014 - 01:59

I came across ‘The Hard Thing About Hard Things‘ while reading an article about Ben Horowitz’s venture capital firm and it was intriguing enough that I bought it and then read through it over a couple of days.

Although the blurb suggests that it’s a book about about building and running a startup I think a lot of the lessons are applicable for any business.

These were some of the main points that stood out for me:

  • The Positivity Delusion – CEOs should tell it like it is.

    My single biggest improvement as CEO occurred on the day when I stopped being too positive.

    Horowitz suggests that he used to be too positive and would shield bad news from his employees as he thought he’d make the problem worse by transferring the burden onto them.

    He came to the realisation that this was counter productive since he often wasn’t the best placed person to fix a problem e.g. if it was a problem with the product then the engineering team needed to know so they could write the code to fix it.

    He goes on to suggest that…

    A healthy company culture encourages people to share bad news. A company that discusses its problems freely and openly can quickly solve them. A company that covers up its problems frustrated everyone involved.

    I’ve certainly worked on projects in the past where the view projected by the most senior person is overly positive and seems to ignore any problems that seem obvious to everyone else. This eventually leads to people being unsure whether to take them seriously which isn’t a great situation to be in.

  • Lead Bullets – fix the problem, don’t run away from it.

    Horowitz describes a couple of situations where his products have been inferior to their competitors and it’s been tempting to take the easy way out by not fixing the product.

    There comes a time in every company’s life where it must fight for its life. If you find yourself running when you should be fighting, you need to ask yourself, “If our company isn’t good enough to win, then do we need to exist at all?”.

    I can’t think of any examples around this from my experience but I really like the advice – I’m sure it’ll come in handy in future.

  • Give ground grudgingly – dealing with the company increasing in size.

    Horowitz suggests that the following things become more difficult as a company grows in size:

    • Communication
    • Common Knowledge
    • Decision Making

    but…

    If the company doesn’t expand it will never be much…so the challenge is to grow but degrade as slowly as possible.

    He uses the metaphor of an offensive linesman in American football who has to stop onrushing defensive linesman but giving ground to them slowly by backing up a little at a time.

    I’ve worked in a few different companies now and noticed things become more structured (and in my eyes worse!) as the company grew over time but I hadn’t really thought about why that was happening. The chapter on scaling a company does a decent job.

  • The Law of Crappy People – people baseline against the worst person at a grade level.

    For any title level in a large organisation, the talent on that level will eventually converge to the crappiest person with that title.

    This is something that he’s also written about on his blog and certainly seems very recognisable.

    His suggestion for mitigating the problem is to have a “properly constructed and highly disciplined promotion process” in place. He describes this like so:

    When a manager wishes to promote an employee, she will submit that employee for review with an explanation of why she believes her employee satisfies the skill criteria required for the level.

    The committee should compare the employee to both the level’s skill description and the skills of the other employees at that level to determine whether or not to approve the promotion.

  • Hire people with the right kind of ambition

    The wrong kind of ambition is ambition for the executive’s personal success regardless of the company’s outcome.

    This suggestion comes from the chapter in which Horowitz discusses how to minimise politics in an organisation.

    I really like this idea but it seems like a difficult thing to judge/achieve. In my experience people often have their own goals which aren’t necessarily completely aligned with the company’s. Perhaps complete alignment isn’t as important unless you’re right at the top of the company?

    He also has quite a neat definition of politics:

    What do I mean by politics? I mean people advancing their careers or agendas by means other than merit and contribution.

    He goes on to describe a few stories of how political behaviour can subtly creep into a company without the CEO meaning for it to happen. This chapter was definitely eye opening for me.

There are some other interesting chapters on the best types of CEOs for different companies, when to hire Senior external people, product management and much more.

I realise that the things I’ve picked out are mostly a case of confirmation bias so I’m sure everyone will have different things that stand out for them.

Definitely worth a read.

Categories: Blogs

Agile Beyond Software

TV Agile - Mon, 10/13/2014 - 21:09
Agile is most closely associated with software development, Agile software development to be precise. That’s enough to put people off right there and then. But for those who listen long enough invariably ask the big question: “Does Agile work outside of software?” This is the question Allan Kelly will attempt to answer in this presentation. […]
Categories: Blogs

Fast and Easy integration testing with Docker and Overcast

Xebia Blog - Mon, 10/13/2014 - 19:40
Challenges with integration testing

Suppose that you are writing a MongoDB driver for java. To verify if all the implemented functionality works correctly, you ideally want to test it against a REAL MongoDB server. This brings a couple of challenges:

  • Mongo is not written in java, so we can not embed it easily in our java application
  • We need to install and configure MongoDB somewhere, and maintain the installation, or write scripts to set it up as part of our test run.
  • Every test we run against the mongo server, will change the state, and tests might influence each other. We want to isolate our tests as much as possible.
  • We want to test our driver against multiple versions of MongoDB.
  • We want to run the tests as fast as possible. If we want to run tests in parallel, we need multiple servers. How do we manage them?

Let's try to address these challenges.

First of all, we do not really want to implement our own MonogDB driver. Many implementations exist and we will be reusing the mongo java driver to focus on how one would write the integration test code.

Overcast and Docker

logoWe are going to use Docker and Overcast. Probably you already know Docker. It's a technology to run applications inside software containers. Overcast is the library we will use to manage docker for us. Overcast is a open source java library
developed by XebiaLabs to help you to write test that connect to cloud hosts. Overcast has support for various cloud platforms, including EC2, VirtualBox, Vagrant, Libvirt (KVM). Recently support for Docker has been added by me in Overcast version 2.4.0.

Overcast helps you to decouple your test code from the cloud host setup. You can define a cloud host with all its configuration separately from your tests. In your test code you will only refer to a specific overcast configuration. Overcast will take care of creating, starting, provisioning that host. When the tests are finished it will also tear down the host. In your tests you will use Overcast to get the hostname and ports for this cloud host to be able to connect to them, because usually these are dynamically determined.

We will use Overcast to create Docker containers running a MongoDB server. Overcast will help us to retrieve the dynamically exposed port by the Docker host. The host in our case will always be the docker host. Docker in our case runs on an external Linux host. Overcast will use a TCP connection to communicate with Docker. We map the internal ports to a port on the docker host to make it externally available. MongoDB will internally run on port 27017, but docker will map this port to a local port in the range 49153 to 65535 (defined by docker).

Setting up our tests

Lets get started. First, we need a Docker image with MongoDB installed. Thanks to the Docker community, this is as easy as reusing one of the already existing images from the Docker Hub. All the hard work of creating such an image is already done for us, and thanks to containers we can run it on any host capable of running docker containers. How do we configure Overcast to run the MongoDB container? This is our minimal configuration we put in a file called overcast.conf:

mongodb {
    dockerHost="http://localhost:2375"
    dockerImage="mongo:2.7"
    exposeAllPorts=true
    remove=true
    command=["mongod", "--smallfiles"]
}

That's all! The dockerHost is configured to be localhost with the default port. This is the default value and you can omit this. The docker image called mongo version 2.7 will be automatically pulled from the central docker registry. We set exposeAllPorts to true to inform docker it needs to dynamically map all exposed ports by the docker image. We set remove to true to make sure the container is automatically removed when stopped. Notice we override the default container startup command by passing in an extra parameter "--smallfiles" to improve testing performance. For our setup this is all we need, but overcast also has support for defining static port mappings, setting environment variables, etc. Have a look at the Overcast documentation for more details.

How do we use this overcast host in our test code? Let's have a look at the test code that sets up the Overcast host and instantiates the mongodb client that is used by every test. The code uses the TestNG @BeforeMethod and @AfterMethod annotations.

private CloudHost itestHost;
private Mongo mongoClient;

@BeforeMethod
public void before() throws UnknownHostException {
    itestHost = CloudHostFactory.getCloudHost("mongodb");
    itestHost.setup();

    String host = itestHost.getHostName();
    int port = itestHost.getPort(27017);

    MongoClientOptions options = MongoClientOptions.builder()
        .connectTimeout(300 * 1000)
        .build();

    mongoClient = new MongoClient(new ServerAddress(host, port), options);
    logger.info("Mongo connection: " + mongoClient.toString());
}

@AfterMethod
public void after(){
    mongoClient.close();
    itestHost.teardown();
}

It is important to understand that the mongoClient is the object under test. Like mentioned before, we borrowed this library to demonstrate how one would integration test such a library. The itestHost is the Overcast CloudHost. In before(), we instantiate the cloud host by using the CloudHostFactory. The setup() will pull the required images from the docker registry, create a docker container, and start this container. We get the host and port from the itestHost and use them to build our mongo client. Notice that we put a high connection timeout on the connection options, to make sure the mongodb server is started in time. Especially the first run it can take some time to pull images. You can of course always pull the images beforehand. In the @AfterMethod, we simply close the connection with mongoDB and tear down the docker container.

Writing a test

The before and after are executed for every test, so we will get a completely clean mongodb server for every test, running on a different port. This completely isolates our test cases so that no tests can influence each other. You are free to choose your own testing strategy, sharing a cloud host by multiple tests is also possible. Lets have a look at one of the tests we wrote for mongo client:

@Test
public void shouldCountDocuments() throws DockerException, InterruptedException, UnknownHostException {

    DB db = mongoClient.getDB("mydb");
    DBCollection coll = db.getCollection("testCollection");
    BasicDBObject doc = new BasicDBObject("name", "MongoDB");

    for (int i=0; i < 100; i++) {
        WriteResult writeResult = coll.insert(new BasicDBObject("i", i));
        logger.info("writing document " + writeResult);
    }

    int count = (int) coll.getCount();
    assertThat(count, equalTo(100));
}

Even without knowledge of MongoDB this test should not be that hard to understand. It creates a database, a new collection and inserts 100 documents in the database. Finally the test asserts if the getCount method returns the correct amount of documents in the collection. Many more aspects of the mongodb client can be tested in additional tests in this way. In our example setup, we have implemented two more tests to demonstrate this. Our example project contains 3 tests. When you run the 3 example tests sequentially (assuming the mongo docker image has been pulled), you will see that it takes only a few seconds to run them all. This is extremely fast.

Testing against multiple MongoDB versions

We also want to run all our integration tests against different versions of the mongoDB server to ensure there are no regressions. Overcast allows you to define multiple configurations. Lets add configuration for two more versions of MongoDB:

defaultConfig {
    dockerHost="http://localhost:2375"
    exposeAllPorts=true
    remove=true
    command=["mongod", "--smallfiles"]
}

mongodb27=${defaultConfig}
mongodb27.dockerImage="mongo:2.7"

mongodb26=${defaultConfig}
mongodb26.dockerImage="mongo:2.6"

mongodb24=${defaultConfig}
mongodb24.dockerImage="mongo:2.4"

The default configuration contains the configuration we have already seen. The other three configurations extend from the defaultConfig, and define a specific mongoDB image version. Lets also change our test code a little bit to make the overcast configuration we use in the test setup depend on a parameter:

@Parameters("overcastConfig")
@BeforeMethod
public void before(String overcastConfig) throws UnknownHostException {
    itestHost = CloudHostFactory.getCloudHost(overcastConfig);

Here we used the paramaterized tests feature from TestNG. We can now define a TestNG suite to define our test cases and how to pass in the different overcast configurations. Lets have a look at our TestNG suite definition:

<suite name="MongoSuite" verbose="1">
    <test name="MongoDB27tests">
        <parameter name="overcastConfig" value="mongodb27"/>
        <classes>
            <class name="mongo.MongoTest" />
        </classes>
    </test>
    <test name="MongoDB26tests">
        <parameter name="overcastConfig" value="mongodb26"/>
        <classes>
            <class name="mongo.MongoTest" />
        </classes>
    </test>
    <test name="MongoDB24tests">
        <parameter name="overcastConfig" value="mongodb24"/>
        <classes>
            <class name="mongo.MongoTest" />
        </classes>
    </test>
</suite>

With this test suite definition we define 3 test cases that will pass a different overcast configuration to the tests. The overcast configuration plus the TestNG configuration enables us to externally configure against which mongodb versions we want to run our test cases.

Parallel test execution

Until this point, all tests will be executed sequentially. Due to the dynamic nature of cloud hosts and docker, nothing limits us to run multiple containers at once. Lets change the TestNG configuration a little bit to enable parallel testing:

<suite name="MongoSuite" verbose="1" parallel="tests" thread-count="3">

This configuration will cause all 3 test cases from our test suite definition to run in parallel (in other words our 3 overcast configurations with different MongoDB versions). Lets run the tests now from IntelliJ and see if all tests will pass:

Screen Shot 2014-10-08 at 8.32.38 PM
We see 9 executed test, because we have 3 tests and 3 configurations. All 9 tests have passed. The total execution time turned out to be under 9 seconds. That's pretty impressive!

During test execution we can see docker starting up multiple containers (see next screenshot). As expected it shows 3 containers with a different image version running simultaneously. It also shows the dynamic port mappings in the "PORTS" column:

Screen Shot 2014-10-08 at 8.50.07 PM

That's it!

Summary

To summarise, the advantages of using Docker with Overcast for integration testing are:

  1. Minimal setup. Only a docker capable host is required to run the tests.
  2. Save time. Minimal amount of configuration and infrastructure setup required to run the integration tests thanks to the docker community.
  3. Isolation. All test can run in their isolated environment so the tests will not affect each other.
  4. Flexibility. Use multiple overcast configuration and parameterized tests for testing against multiple versions.
  5. Speed. The docker container starts up very quickly, and overcast and testng allow you to even parallelize the testing by running multiple containers at once.

The example code for our integration test project is available here. You can use Boot2Docker to setup a docker host on Mac or Windows.

Happy testing!

Paul van der Ende 

Note: Due to a bug in the gradle parallel test runner you might run into this random failure when you run the example test code yourself. The work around is to disable parallelism or use a different test runner like IntelliJ or maven.

 

Categories: Companies

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.