Skip to content


Distributed Scrum Development with Jenkins

TV Agile - Mon, 08/25/2014 - 18:00
This presentation discusses the experience of using Jenkins to manage the full stack integration build and testing for DealerTrack 2.0 for more than six distributed Scrum teams. Topics include: * Jenkins master-slave strategy * Hot-fixes vs. development build * Vagrant for isolated build environment * Fabric for deployment * Robotframework-Selenium for acceptance test * Best […]
Categories: Blogs

How Can Enterprise Architects Drive Business Value the Agile Way?

J.D. Meier's Blog - Mon, 08/25/2014 - 17:48

An Enterprise Architect can have a tough job when it comes to driving value to the business.   With multiple stakeholders, multiple moving parts, and a rapid rate of change, delivering value is tough enough.   But what if you want to accelerate value and maximize business impact?

Enterprise Architects can borrow a few concepts from the Agile world to be much more effective in today’s world.

A Look Back at How Agile Helped Connect Development to Business Impact …

First, let’s take a brief look at traditional development and how it evolved.  Traditionally, IT departments focused on delivering value to the business by shipping big bang projects.   They would plan it, build it, test it, and then release it.   The measure of success was on time, on budget.   

Few projects ever shipped on time.  Few were ever on budget.  And very few ever met the requirements of the business.

Then along came Agile approaches and they changed the game.

One of the most important ideas was a shift away from thick requirements documentation to user stories.  Developers got customers telling stories about what they wanted the future solution to do.  For example, a user story for a sale representative might look like this:

“As a sales rep, I want to see my customer’s account information so that I can identify cross-sell and upsell opportunities.” 

The use of user stories accomplished several things.   First, user stories got the development teams talking to the business users.  Rather than throwing documents back and forth, people started having face-to-face communication to understand the user stories.  Second, user stories helped chunk bigger units of value down into smaller units of value.  Rather than a big bang project where all the value is promised at the end of some long development cycle, a development team could now ship the solution in increments, where each increment was a prioritized set of stories.   The user stories effectively create a shared language for value

Third, it made it easier to test the delivery of value.  Now the user and the development team could test the solution against the user stories and acceptance criteria.  If the story met acceptance criteria, the user would acknowledge that the value was delivered.  In this way, the user stories created both a validation mechanism and a feedback loop for delivering and acknowledging value.

In the Agile world, bigger stories are called epics, and collections of stories are called themes.  Often a story starts off as an epic until it gets broken down into multiple stories.  What’s important here is that the collections of stories serve as a catalog of potential value.   Specifically, this catalog of stories reflects potential value with real stakeholders.  In this way, Agile helps drive customer focus and customer connection.  It’s really effective stakeholder management in action.

Agile approaches have been used in software projects large and small.  And they’ve forever changed how developers and project managers approach projects.

A Look at How Agile Can Help Enterprise Architecture Accelerate Business Value …

But how does this apply to Enterprise Architects?

As an Enterprise Architect, chances are you are responsible for achieving business outcomes.  You do this by driving business transformation.   The way you achieve business transformation is through driving capability change including business, people, and technical capabilities.

That’s a tall order.   And you need a way to chunk this up and make it meaningful to all the parties involved.

The Power of Scenarios as Units of Value for the Enterprise

This is where scenarios come into play.  Scenarios are a simple way to capture pains, needs and desired outcomes.   You can think of the desired outcome as the future capability vision.   It’s really a story that helps articulate the art of the possible.   More precisely, you can use scenarios to help build empathy with stakeholders for what value will look like, by painting a conceptual scene of the future.

An Enterprise scenario is simply a chunk of organizational change, typically about 3-5 business capabilities, 3-5 people capabilities, and 3-5 technical capabilities.

If that sounds like a lot of theory, let’s step into an example to show what it looks like in practice.

Let’s say you’re in a situation where you need to help a healthcare provider change their business.  

You can come up with a lot of scenarios, but it helps to start with the pains and needs of the business owner.  Otherwise, you might start going through a bunch of scenarios for the patients or for the doctors.  In this case, the business owner would be the Chief Medical Officer or the doctor of doctors.

Scenario: Tele-specialist for Healthcare

If we walk the pains, needs, and desired outcomes of the Chief Medical Officer, we might come up with a scenario that looks something like this, where the CURRENT STATE reflects the current pains, and needs, and the FUTURE STATE reflects the desired outcome.


Here is an example of the CURRENT STATE portion of the scenario:

The Chief Medical Officer of Contoso Provider is struggling with increased costs and declining revenues. Costs are rising due to the Affordable Healthcare Act regulatory compliance requirements and increasing malpractice insurance premiums. Revenue is declining due to decreasing medical insurance payments per claim.


Here is an example of the FUTURE STATE portion of the scenario:

Doctors can consult with patients, peers, and specialists from anywhere. Contoso provider's doctors can see more patients, increase accuracy of first time diagnosis, and grow revenues.



Storyboard for the Future Capability Vision

It helps to be able to picture what the Future Capability Vision might look like.   That’s where storyboarding can come in.  An Enterprise Architect can paint a simple scene of the future with a storyboard that shows the Future Capability Vision in action.  This practice lends itself to whiteboarding, and the beauty of a whiteboard is you can quickly elaborate where you need to, without getting mired in details.


As you can see in this example storyboard of the Future Capability Vision, we listed out some business benefits, which we could then drill-down into relevant KPIs and value measures.   We’ve also outlines some building blocks required for this Future Capability Vision in the form of business capabilities and technical capabilities.

Now this simple approach accomplishes a lot.   It helps ensure that any technology solution actually connects back to business drivers and pains that a business decision maker actually cares about.   This gets their fingerprints on the solution concept.   And it creates a simple “flashcard” for value.   If we name the Enterprise scenario well, then we can use it as a handle to get back to the story we created with the business of a better future.

The obvious thing this does, aside from connecting IT to the business, is it helps the business justify any investment in IT.

And all we did was walk through one Enterprise Scenario.  

But there is a lot more value to be found in the Enterprise.   We can literally explore and chunk up the value in the Enterprise if we take a step back and add another tool to our toolbelt:  the Scenario Chain.

Scenario Chain:  Chaining the Industry Scenarios to Enterprise Scenarios

The Scenario Chain is another powerful conceptual visualization tool.  It helps you quickly map out what’s happening in the marketplace in terms of industry drivers or industry scenarios.  You can then identify potential investment objectives.   These investment objectives lead to patterns of value or patterns of solutions in the Enterprise, which are effectively Enterprise scenarios.   From the Enterprise scenarios, you can then identify relevant usage scenarios.  The usage scenarios effectively represent new ways of working for the employees, or new interaction models with customers, which is effectively a change to your value stream.


With one simple glance, the Scenario Chain is a bird’s-eye view of how you can respond to the changing marketplace and how you can transform your business.   And, by using Enterprise scenarios, you can chunk up the change into meaningful units of value that reflect pains, needs, and desired outcomes for the business.  And, because you have the fingerprints of stakeholders from both business and IT, you’ve effectively created a shared vision for the future, that has business impact, a justification for investment, and it creates a pull-through mechanism for additional value, by driving the adoption of the usage scenarios.

Let’s elaborate on adoption and how scenarios can help accelerate business value.

Using Scenario to Drive Adoption and Accelerate Business Value

Driving adoption is a key way to realize the business value.  If nobody adopts the solution, then that’s what Gartner would call “Value Leakage.”  Value Realization really comes down to governance, measurement, and adoption.

With scenarios at your fingertips, you have a powerful way to articulate value, justify business cases, drive business transformation, and accelerate business value.   The key lies in using the scenarios as a unit of value, and focusing on scenarios as a way to drive adoption and change.

Here are three ways you can use scenarios to drive adoption and accelerate business value:

1.  Accelerate Business Adoption

One of the ways to accelerate business value is to accelerate adoption.    You can use scenarios to help enumerate specific behavior changes that need to happen to drive the adoption.   You can establish metrics and measures around specific behavior changes.   In this way, you make adoption a lot more specific, concrete, intentional, and tangible.

This approach is about doing the right things, faster.

2.  Re-Sequence the Scenarios

Another way to accelerate business value is to re-sequence the scenarios.   If your big bang is way at the end (way, way at the end), no good.  Sprinkle some of your bangs up front.   In fact, a great way to design for change is to build rolling thunder.   Put some of the scenarios up front that will get people excited about the change and directly experiencing the benefits.  Make it real.

The approach is about putting first things first.

3.  Identify Higher Value Scenarios

The third way to accelerate business value is to identify higher-value scenarios.   One of the things that happens along the way, is you start to uncover potential scenarios that you may not have seen before, and these scenarios represent orders of magnitude more value.   This is the space of serendipity.   As you learn more about users and what they value, and stakeholders and what they value, you start to connect more dots between the scenarios you can deliver and the value that can be realized (and therefore, accelerated.)

This approach is about trading up for higher value and more impact.

As you can see, Enterprise Architects can drive business value and accelerate business value realization by using scenarios and storyboarding.   It’s a simple and agile approach for connecting business and IT, and for shaping a more Agile Enterprise.

I’ll share more on this topic in future posts.   Value Realization is an art and a science and I’d like to reduce the gap between the state of the art and the state of the practice.

You Might Also Like

3 Ways to Accelerate Business Value

6 Steps for Enterprise Architecture as Strategy

Cognizant on the Next Generation Enterprise

Simple Enterprise Strategy

The Mission of Enterprise Services

The New Competitive Landscape

What Am I Doing on the Enterprise Strategy Team?

Why Have a Strategy?

Categories: Blogs

Capacity Planning and the Project Portfolio

Johanna Rothman - Mon, 08/25/2014 - 15:17

I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red flag #1)

The worst part? They don’t have feature teams. They have component teams: front end, middleware, back end. You might, too. (Red flag #2)

Problem #1: They have a very large program, not a series of unrelated projects. They also have projects.

Problem #2: They want to use capacity planning, instead of flowing work through teams.

They are setting themselves up to optimize at the lowest level, instead of optimizing at the highest level of the organization.

If you read Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, you understand this problem. A program is a strategic collection of projects where the business value of the all of the projects is greater than any one of the projects itself. Each project has value. Yes. But all together, the program, has much more value. You have to consider the program has a whole.

Don’t Predict the Project Portfolio Based on Capacity

If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it.

First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways.

When you have component teams, not feature teams, their interdependencies are significant and unpredictable. Your ability to predict the future based on past velocity? Zero. Nada. Zilch.

This is legacy thinking from waterfall. Well, you can try to do it this way. But you will be wrong in many dimensions:

  • You will make mistakes because of prediction based on estimation. Estimates are guesses. When you have teams using relative estimation, you have problems.
  • Your estimates will be off because of the silent interdependencies that arise from component teams. No one can predict these if you have large stories, even if you do awesome program management. The larger the stories, the more your estimates are off. The longer the planning horizon, the more your estimates are off.
  • You will miss all the great ideas for your project portfolio that arise from innovation that you can’t predict in advance. As the teams complete features, and as the product owners realize what the teams do, the teams and the product owners will have innovative ideas. You, the management team, want to be able to capitalize on this feedback.

It’s not that estimates are bad. It’s that estimates are off. The more teams you have, the less your estimates are normalized between teams. Your t-shirt sizes are not my Fibonacci numbers, are not that team’s swarming or mobbing. (It doesn’t matter if you have component teams or feature teams for this to be true.)

When you have component teams, you have the additional problem of not knowing how the interdependencies affect your estimates. Your estimates will be off, because no one’s estimates take the interdependencies into account.

You don’t want to normalize estimates among teams. You want to normalize story size. Once you make story size really small, it doesn’t matter what the estimates are.

When you  make the story size really small, the product owners are in charge of the team’s capacity and release dates. Why? Because they are in charge of the backlogs and the roadmaps.

The more a program stops trying to estimate at the low level and uses small stories and manages interdependencies at the team level, the more the program has momentum.

The part where you gather all the projects? Do that part. You need to see all the work. Yes. that part works and helps the program see where they are going.

Use Value for the Project Portfolio

Okay, so you try to estimate the value of the features, epics, or themes in the roadmap of the project portfolio. Maybe you even use the cost of delay as Jutta and I suggest in Diving for Hidden Treasures: Finding the Real Value in Your Project Portfolio (yes, this book is still in progress). How will you know if you are correct?

You don’t. You see the demos the teams provide, and you reassess on a reasonable time basis. What’s reasonable? Not every week or two. Give the teams a chance to make progress. If people are multitasking, not more often than once every two months, or every quarter. They have to get to each project. Hint: stop the multitasking and you get tons more throughput.

Categories: Blogs

Scrum in der Medizintechnik: Wie stelle ich ein erfolgreiches Team zusammen?

Scrum 4 You - Mon, 08/25/2014 - 07:30

Auch in stark regulierten Branchen wie der Medizintechnik ist es möglich, Produkte mit Scrum zu entwickeln – das hat sich mittlerweile von den IT-Abteilungen deutscher Dienstleistungsunternehmen über den innovativen Mittelstand bis in die großen Konzerne durchgesprochen*. Aber wo anfangen, wenn die Entscheidung für Scrum einmal gefällt wurde? Der Erfolg Ihres Projekts steht und fällt mit dem Team.

Scrum, richtig gelebt, bietet Ihnen die Möglichkeit, sämtliches Know-how, das Sie für die Entwicklung Ihres Produkts benötigen, in einem Team zu bündeln. Auf diese Weise lassen sich zusätzliche Aufwände und Redundanzen an Übergabepositionen minimieren und gleichzeitig dringend benötigtes Wissen beinahe automatisch auf mehrere Köpfe verteilen.


Herausforderungen für die Medizintechnik

Für die Hersteller medizintechnischer Geräte bedeutet das allerdings nicht nur, Anwendungsentwickler und Tester zusammenzusetzen. Zu der ohnehin schon komplexen Aufgabe, Hardware und Software miteinander zu kombinieren, kommt hinzu, dass konstruierte Teile bestellt, Risikomanagement-Checklisten abgearbeitet und vor allem regulatorische Anforderungen erfüllt werden müssen. Neben Hard- und Softwareentwicklern sowie Konstrukteuren brauchen Sie in Ihrem Team also auch noch einen Einkäufer, jemanden aus der Produktdokumentation und eine Person, die sich mit den regulatorischen Anforderungen auskennt.

Pilotteams nicht als Wetterfrösche missbrauchen!

Viele Unternehmen treffen die Entscheidung, Scrum zunächst in Pilotprojekten auszuprobieren, um die Organisation nicht zu überfordern und ein Gefühl dafür zu bekommen, ob das funktionieren kann, oder nicht. Der Gedanke, die Organisation nicht zu überrumpeln, ist nachvollziehbar, und das Aufsetzen einer Pilotgruppe auch empfehlenswert.

Aber: Jedes Pilot-Team wird früher oder später an strukturelle Grenzen stoßen, vor allem wenn die Abteilungen, die den Teams zuarbeiten, nicht entsprechend geschult sind. Insbesondere wenn es um Anforderungen „aus dem Feld“ oder seitens der Regulierungsbehörden geht, kann die Integration entsprechender Know-how-Träger in ein Scrum-Team sehr viel Zeit sparen. Heißt das, mein QM – Mitarbeiter ist jetzt 100% der Zeit im Scrum-Team? Nicht unbedingt.

Verantwortungsbewusstsein schaffen

Allein das Commitment „entwicklungsfernerer“ Kollegen, regelmäßig zu Meetings wie Sprint Planning, Daily oder Review zu erscheinen, wird einen großen Beitrag zu mehr Effizienz Ihrer Scrum-Teams leisten.

Bei einem unserer Kunden in der Laborautomatisierung gibt es beispielsweise einen Projekteinkäufer, der regelmäßig die Dailies mehrerer Scrum Teams besucht und somit für das Team stets zu verlässlichen Zeitpunkten als Ansprechpartner zur Verfügung steht, sollte es beispielsweise Rückfragen zu Lieferzeiten geben. Und auch für die Arbeit des Projekteinkäufers ergeben sich durch die Unmittelbarkeit viele Vorteile. So bekommt er schnell ein Gefühl für die Dringlichkeit sowie über mögliche Zusammenhänge einzelner Bestellungen.

Auch bei der Erstellung von Bedienungs- oder Servicehandbüchern lassen sich eine Vielzahl von Verzögerungen und doppelten Arbeitsschritten durch die rechtzeitige Einbindung entsprechender Kollegen vermeiden. Schaffen Sie ein Bewusstsein dafür, dass Ihr Projekt nur durch das Zusammenwirken aller Parteien erfolgreich werden kann und das Scrum hierfür den notwendigen Rahmen bietet. Haben Sie die Rahmenbedingungen einmal abgesteckt und kommuniziert, werden sich Ihre Teams so aufstellen, wie sie es für eine anwenderfreundliche und normgerechte Produktentwicklung brauchen.

*Sowohl der Technical Information Report TIR 45:2012 der AAMI (Association for the Advancement of Medical Instrumentation ) als auch die Prozess-Norm IEC 62304 geben Herstellern explizit die Freiheit, ihre Produkte so zu entwickeln, wie sie es für richtig halten – solange die Produktsicherheit und -qualität gewährleistet bleiben.

Related posts:

  1. Wann ist ein ScrumMaster erfolgreich?
  2. Portfolio
  3. Auch wenn’s mal wieder länger dauert: Pull die wichtigsten Themen zuerst

Categories: Blogs

"How Thin is Thin?" An Example of Effective Story Slicing

Practical Agility - Dave Rooney - Sun, 08/24/2014 - 19:00
Graphene is pure carbon in the form of a very thin, nearly transparent sheet, one atom thick. It is remarkably strong for  its very low weight and it conducts heat and electricity with great efficiency. Wikipedia If you have spent any time at all working in an Agile software development environment, you've heard the mantra to split your Stories as thin as you possibly can while still
Categories: Blogs

Tipps zum Schreiben: Ein Sonntagserlebnis

Scrum 4 You - Sun, 08/24/2014 - 16:30

Ich werde immer wieder gefragt (meist von meinen Kollegen), wie ich es schaffe, neben meinen Trainings und Consulting-Aufträgen auch noch Bücher zu schreiben und Blogbeiträge zu verfassen. Es ist ganz einfach: Ich schreibe. Ich erzähle euch mal, wie so ein Tag aussehen kann.

Heute – Sonntag – habe ich meine Frau und eine Freundin auf ein Reitturnier begleitet. Wir sind um 06:00 aufgestanden, um 07:00 habe ich unser Pferd Rübe geputzt, dann sind wir eine Stunde gefahren und irgendwann gab es für mich mal eine Pause von 20 Minuten. Ich habe mir einen Kaffee gekauft, mich hingesetzt mein derzeit favorisiertes Schreibprogram Writer, ein Google Chrome Plugin, gestartet und geschrieben.

20 Minuten später kam meine Frau, ihre Freundin brauchte Hilfe mit ihrem Pferd. Also den Rechner zugeklappt, eingepackt und in den nächsten zwei Stunden zugeschaut, wie die beiden sehr erfolgreich waren. Dann gab es wieder 10 Minuten: Den Rechner rausgeholt unter den Baum gesetzt und da weitergeschrieben, wo ich aufgehört hatte. Klar muss ich dann immer den vorherigen Absatz umschreiben um reinzukommen, aber ich konnte wieder einige hundert Worte schreiben. Meine Frau kommt vorbei und bittet mich, das Pferd zu halten. Ich klappe den Rechner wieder zu. Dann waren wir fertig, haben die Pferde in den Stall zurückgebracht, die beiden anderen Pferde versorgt und sind nach Hause gefahren. Dort geduscht, etwas gegessen und meine Frau ist noch einmal zu den Pferden gefahren (das ist heute eine Ausnahme) und ich sitze seit 75 Minuten hier am Küchentisch und schreibe.

Zugegeben, ein solcher Tag ist auch für mich eine Ausnahme. Ich bin gerade wieder vom Schreiben gefangen. Sonst würde ich nicht in den “Auszeiten” schreiben. In den letzten 8 Wochen, nachdem ich das Manuskript zu “Selbstorganisation braucht Führung” an Dolores, meine Editorin, abgegeben habe, war ich erst einmal fertig mit Schreiben. Ausgeschrieben. Doch die letzten Blogs, von denen ihr in den letzten Tagen wieder einige lesen konntet, zeigen, dass es so viel zu bemerken gibt, das muss einfach zu Papier bzw. zu Datei gebracht werden. Normalerweise schreibe ich morgens, kurz nach dem Aufstehen, oder abends im Hotel, am Flughafen, wenn ich auf den Flieger warte, im Zug nach irgendwohin.

“Aber wie macht er das?”, höre ich fragen. Einem guten Freund von mir passiert das Gleiche beim Fotografieren. Er macht Fotos. Ständig. Ein anderer malt. Ich schreibe – ich denke dabei nicht nach, sondern ich schreibe. Manchmal wird es gut, manchmal sehr gut. Brauchbar ist es mittlerweile immer – aber das ist Übung. Macht es Spaß? Ohne Ende.

Versucht es auch, ich kann es nur empfehlen. Hört einfach auf darüber nachzudenken, was ihr schreiben wollt und schreibt.

Related posts:

  1. Führung ist?
  2. Über das Schreiben: Leidenschaft | Passion | Freewriting
  3. Bin ich am Arbeitsplatz zufrieden?

Categories: Blogs

Listen, Test, Code, Design OVER Sprints, Scrums, and ScrumMasters

"Back to basics" is Scrum?I've been noticing people talk about getting "back to the basics" and then proceed to talk about Scrum roles and rituals.

This annoys me for 2 main reasons:
  1.  Scrum was never "basics" for me and I've typically been doing this longer than the person who suggests this
  2. The more important reason is that if we think about this carefully, Scrum cannot be the "basics"
"Back to basics" should be about the essence of what we are doing"Back to basics", "focusing on the fundamentals", etc. is about getting back to the essence of an activity.  I touched upon this when I was exploring the concept of doctrine but let's think about this using the frame of "basics" or "fundamentals".

If we look at the context of developing software for a purpose, as opposed to as a hobby, what is the essence of what needs to happen?
  1. You need a shared understanding of what problem the software is intended to solve.  We have learned that the best way to do this is to engage directly with the relevant situation and people.
  2. You need a shared understanding of what the solution needs to do to solve the problem.  We have learned that the best way to do this is through conversations leading to agreed examples and then iterating.
  3. You need to build the solution.  We have learned that the best way to do this is in a thoughtful, collaborative, disciplined way.
  4. You need to manage the growing complexity of the system to ensure that it continues to be easy to change.  We have learned that the best way to do this is as an ongoing exercise reflecting the best knowledge we have at each point.
A more compact version of this might be: Listen, Test, Code, Design.
If you don't get good at these basics, all your Sprints, Scrums, and ScrumMasters won't matter much.
Categories: Blogs

Measuring Business value in Agile projects

Agile World - Venkatesh Krishnamurthy - Sun, 08/24/2014 - 01:44


Because the first principle of the Agile Manifesto talks about delivering valuable software to the customer, many agile practitioners are constantly thoughtful of the value in each step of the software-development lifecycle.

At the thirty-thousand-foot level, value creation starts with gathering requirements and continues with backlog creation, backlog grooming, writing user stories, and development, finally ending with integration, deployment, and support. Even with knowledge of all these moving parts, it is common to see organizations only measuring value during development and ignoring the rest of the steps.

What’s the fix? During backlog creation, user stories need to be compared and contrasted in order to promote maximum value delivery. The product owner might need to use different techniques, such as T-shirt sizing, in order to better prioritize the project’s stories.

An alternate approach to measuring the business value of user stories is to use a three-dimensional metric that incorporates complexity, business value, and the ROI. Creating value can often require a change in perspective from the normal project’s tasks and functions. Thinking outside the box, identifying business value before writing the user stories is much better than writing and then trying to evaluate.

Read  the complete article about measuring business value on TechWell

Picture courtesy

Categories: Blogs

New Foundations 3.0 Webinar

Agile Product Owner - Sat, 08/23/2014 - 16:26


We’ve just posted an updated introductory Webinar: SAFe Foundations: Be Agile. Scale Up. Stay Lean. at ScaledAgileFramework/foundations. “Foundations” is the free Powerpoint briefing (download from the same page) that you can use in most any context to describe SAFe to your intended audience.

In this 45 minute webinar, I walk through the Foundations PPT and describe:

  • The rationale for Agile and SAFe
  • A bit of SAFe history
  • SAFe core values
  • Business benefits enterprises have achieved with SAFe
  • Lean Thinking overview
  • A brief overview, of SAFe Team, Program, and Portfolio levels
  • Introduction to the Principles of Lean Leadership
  • Next Steps and Implementation 1-2-3 Guidance

Thanks to Jennifer Fawcett for hosting the event.

Categories: Blogs

Why Iterative Planning?

Leading Agile - Mike Cottmeyer - Fri, 08/22/2014 - 17:40

First, I would like to credit Eric Ries in his 2010 Web 2.0 speech for giving me the idea for these awesome graphics. If you have never seen the speech then I highly recommend the version found on YouTube. I have always admired people with creative slides who can capture ideas with elegant simplicity. Since my artistic ability peaked in the first grade, the images in this post demonstrate my foray into abstract expressionism and hopefully convey the point of why we in software need iterative planning.

Unknown Problem | Unknown Solution

Most software changes start life in the state of an unknown problem with an unknown solution. Iterative planning graphNow the product mangers reading this may beg to differ but, most of the time a vague idea on having the software do something is not a known problem space. Say for instance I want to allow uninsured people to buy insurance as a government subsidized rate.  Most of us can imagine that this is a huge problem space and truly we would have no idea how to make this happen.  In this case the problem space and the solution space is unknown.  In order to plan a software delivery that will solve the want above, I need to clearly understand the problem that needs to be solved.  To do this in agile software delivery we create something called a roadmap.  The roadmap is a way of breaking this big unknown problem into smaller chucks that we can estimate (“guess wrong”) as to how long it will take to implement them.  It is usually at this stage that these chunks of work are funded.

Known Problem | Unknown Solution

Now a software releasIterative planning graphe is ready to be planned with some chunk of the roadmap.  In order to do that, the problem should be fairly well known and can be broken it into pieces.  These pieces can be estimated (“guessed wrong”) and slotted into delivery iterations.  Lets say we want to allow people to log into a website and sign up for insurance.  This is a relatively well-known problem space, there are security concerns, 3rd party integrations, databases, platforms and deployments.  Maybe this will not all fit in one release, but with more elaboration and planning a reasonable release plan with a list of risks will emerge. It is usually at this stage that the guess of the size of the thing in the roadmap is known to be wrong and changes must be made to the roadmap.

Known Problem | Known Solution

Iterative planning graphFinally we are ready to plan an iteration. So take a chunk of the release plan and break it into pieces and as a team there needs to be some certainty that these pieces of work can be completed in the sprint. If there are still things that don’t have a clear solution then don’t take those in the sprint and take a spike or research item instead. It is now that the wrongness of the guess during release planning is known and adjustments can be made both to the release plan and the roadmap.

Planning and elaboration go hand in hand as items move from unknown problem -unknown solution to known problem-unknown solution to known problem – known solution.

The post Why Iterative Planning? appeared first on LeadingAgile.

Categories: Blogs

GOAT14 – Call for Speakers

Notes from a Tool User - Mark Levison - Fri, 08/22/2014 - 15:41

This year’s Gatineau Ottawa Agile Tour (#GOAT14) will take place on Monday, November 24th 2014, and Agile Pain Relief Consulting is once again a proud sponsor. Organizers are looking for engaging and inspirational speakers for this year’s conference. If you are interested in participating, please submit a proposal by completing the online form at The organizing committee will select speakers based on the following criteria:

  • Learning potential for and appeal to participants
  • Practicality and usefulness/applicability of content to the workplace
  • Overall program balance Speaker’s experience and reputation
  • Interactive elements (i.e. exercises, simulations, questions…)

Deadline for proposals: Sunday September 15th at 23:59pm

About the Gatineau – Ottawa Agile Tour
The Gatineau – Ottawa Agile Tour (#GOAT14) is a full day of conferences around the theme of Agility applied to software development, but also to management, marketing, product management and other areas of today’s businesses.

Categories: Blogs

Neo4j: LOAD CSV – Handling empty columns

Mark Needham - Fri, 08/22/2014 - 14:51

A common problem that people encounter when trying to import CSV files into Neo4j using Cypher’s LOAD CSV command is how to handle empty or ‘null’ entries in said files.

For example let’s try and import the following file which has 3 columns, 1 populated, 2 empty:

$ cat /tmp/foo.csv
load csv with headers from "file:/tmp/foo.csv" as row
MERGE (p:Person {a: row.a})
SET p.b = row.b, p.c = row.c

When we execute that query we’ll see that our Person node has properties ‘b’ and ‘c’ with no value:

==> +-----------------------------+
==> | p                           |
==> +-----------------------------+
==> | Node[5]{a:"mark",b:"",c:""} |
==> +-----------------------------+
==> 1 row
==> Nodes created: 1
==> Properties set: 3
==> Labels added: 1
==> 26 ms

That isn’t what we want – we don’t want those properties to be set unless they have a value.

TO achieve this we need to introduce a conditional when setting the ‘b’ and ‘c’ properties. We’ll assume that ‘a’ is always present as that’s the key for our Person nodes.

The following query will do what we want:

load csv with headers from "file:/tmp/foo.csv" as row
MERGE (p:Person {a: row.a})
FOREACH(ignoreMe IN CASE WHEN trim(row.b) <> "" THEN [1] ELSE [] END | SET p.b = row.b)
FOREACH(ignoreMe IN CASE WHEN trim(row.c) <> "" THEN [1] ELSE [] END | SET p.c = row.c)

Since there’s no if or else statements in cypher we create our own conditional statement by using FOREACH. If there’s a value in the CSV column then we’ll loop once and set the property and if not we won’t loop at all and therefore no property will be set.

==> +-------------------+
==> | p                 |
==> +-------------------+
==> | Node[4]{a:"mark"} |
==> +-------------------+
==> 1 row
==> Nodes created: 1
==> Properties set: 1
==> Labels added: 1
Categories: Blogs

R: Rook – Hello world example – ‘Cannot find a suitable app in file’

Mark Needham - Fri, 08/22/2014 - 13:05

I’ve been playing around with the Rook library and struggled a bit getting a basic Hello World application up and running so I thought I should document it for future me.

I wanted to spin up a web server using Rook and serve a page with the text ‘Hello World’. I started with the following code:

s <- Rhttpd$new()

where helloWorld.R contained the following code:

    headers = list(
      'Content-Type' = 'text/html'
    body = paste('<h1>Hello World!</h1>')

Unfortunately that failed on the ‘s$add’ line with the following error message:

> s$add(name='MyApp',app='helloworld.R')
Error in .Object$initialize(...) : 
  Cannot find a suitable app in file helloworld.R

I hadn’t realised that you actually need to assign that function to a variable ‘app’ in order for it to be picked up:

app <- function(env){ 
    headers = list(
      'Content-Type' = 'text/html'
    body = paste('<h1>Hello World!</h1>')

Once I fixed that everything seemed to work as expected:s

> s
Server started on
[1] MyApp
Call browse() with an index number or name to run an application.
Categories: Blogs

Die Frage nach dem Warum

Scrum 4 You - Fri, 08/22/2014 - 07:30

Als ScrumMaster bzw. Agile Consultant stelle ich am Anfang von jedem Scrum Meeting immer dieselbe offene Frage in die Runde der Teilnehmer: „Weshalb ist dieses Meeting Teil des Scrum Flows?“ Wohlgemerkt: Das frage ich nicht nur, wenn ich ein Team gerade neu übernommen habe, oder wenn wir einen Termin neu gestalten. Für mich hat diese Frage einen positiven Aspekt, den man immer wieder wiederholen darf – jenen des kontinuierlichen Lernens und der Frage nach dem Sinn.

Eines habe ich nämlich durch Scrum gelernt: Es hat alles einen Sinn. Und wenn etwas tatsächlich doch keinen Sinn hat, dann ist es Waste und sollte tunlichst geändert bzw. abgeschafft werden! Da wir als Firma Boris Gloger Consulting immer öfter von Managern angerufen werden, um Scrum in ihren Unternehmen zu implementieren, hat der Begriff „Scrum“ bei vielen Mitarbeitern auch das Synonym „neuester Trend“. Gerade dienstältere Mitarbeiter belächeln mich dann manchmal und meinen nur „Sie wissen ja gar nicht, wie viele Prozesse wir hier schon kommen und gehen gesehen haben. Dieses Scrum wird der nächste gewesen sein“. Dagegen weigere ich mich jedoch. Ja, es ist aktuell trendy, agil zu arbeiten (siehe „Studie Agile Status Quo“). Doch gibt es auch einen guten Grund dafür!

Damit Scrum nicht nur als Trend wahrgenommen und gelebt wird, ist es wichtig, dass jene Menschen, die
damit arbeiten sollen, den Sinn dahinter erkennen. Und aus diesem Grund stelle ich die Frage nach dem „Warum“ am Anfang jedes (Scrum-)Meetings. Auch vor kurzem wieder am Anfang der Sprinthe-question-mark-350169_640t Retrospektive bei einem cross-funktionalen Team, das schon seit einem Jahr Scrum in der Hardware macht. Kleiner Tipp am Rande: Hört gut zu. Die erste Antwort beantwortet meistens das Was. Auch dieses Mal kam wieder die Antwort: „Wir schauen uns an, was im letzten Sprint gut gelaufen ist und was wir im nächsten Sprint anders machen wollen“. Ja – das ist korrekt. Doch beantwortet das meine Frage nach dem Warum? Nein. Also noch einmal fragen: „Weshalb sitzen wir jetzt in diesem Meeting?“

Ein schöner Nebeneffekt dieser offenen Frage ist, dass es Zynismus und lustige Kommentare zulässt. So kann man gleich mit einem Lachen in ein Meeting starten. Oder Bedenken aus dem Weg räumen. Falsche Interpretationen gerade ziehen. Einen Einblick in die Stimmung im Team bekommen. Und auch als Agile Consultant immer wieder Neues erfahren.

Versucht es selbst! Ich freue mich über Erfahrungsberichte.

Related posts:

  1. Die Retrospektive macht das Team, das Team macht die Retrospektive
  2. Scrum – wider die Methodenfixierung
  3. Klassiker | Sprint Planning

Categories: Blogs

The Agile Reader – Weekend Edition: 08/22/2014 - Kane Mar - Fri, 08/22/2014 - 05:43

You can get the Weekend Edition delivered directly to you via email by signing up here.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • What’s going on? Agile and Scrum Certification Online Free Webinar On How are Agile…
  • RT @magenic: How do you define success in an #agile environment? #scrum
  • “@bfavellato: Tutorials, Practices & Demos: IBM Rational Solution for #Agile ALM with Scrum @JazzDotNet @JazzHub”
  • RT @pisarose: Great ideas! A scrum approach to #content creation – @shellykramer #marketing #agile
  • 8 Ways to Avoid Making an #Agile Mistake #agiledevelopment #scrum
  • Interesting reading for the next week #agile #scrum #gamedev
  • RT @apuntoprieto: Interesting reading for the next week #agile #scrum #gamedev
  • <a href="
    Warning: require_once(/home3/clinton3/public_html/wp-settings.php): failed to open stream: No such file or directory in /home3/clinton3/public_html/wp-config.php on line 30”>RT : Interesting reading for the next week #agile #scrum #gamedev
  • Keep it Simple: What is Agile SCRUM: #scrum #agile
  • How to help a team that is not performing so well – Part I – #scrum #agile #learning #improvement
  • RT @AgileBelgium: #Agile Tour Brussels 2014: program published, registration open. #atbru #program #published #scrum…
  • RT @yochum: Scrum Expert: Patterns: a New Standard for Scrum #agile #scrum
  • Read this #Kindle #8399

    The Scrum Checklist, For the Agile Scrum Master, Product Owner,…

  • Read this #Kindle #8399

    How to Become a Scrum Master in 7 Simple Steps (Agile Project M…

  • Read this #Kindle #8399

    Scrum, (Mega Pack), For the Agile Scrum Master, Product Owner, …

  • Interested in this job? Eliassen Group Agile Coaching & Senior Scrum Master Training in Bethesda, MD #agilecoach
  • Agile Transformation Program Manager – Scrum Master – 8188 #job
  • Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #AppsTrans #HP
  • Using personas to drive epic & user story development: by @romanpichler #prodmgmt #agile #scrum
  • RT @lgoncalves1979: How to help a team that is not performing so well – Part I – #scrum #agile #learning #improvement
  • Are you thinking about getting a Scrum Master Certification? #agile #scrum
  • Here is my half day w/shop presentation on Leading Agile Virtual Teams, delivered at #LEADit #scrum #virtualteams
  • “Scrum is a means of becoming agile…but you can, and should outgrow it if you do it right.” @geoffcwatts #scrumish
  • Here is our half day w/shop presentation on Leading Agile Virtual Teams, delivered at #LEADit #scrum #virtualteams
  • CHECK THIS #BOOK #71084 #Kindle

    The Scrum Checklist, For the Agile Scrum Master, Produc…

  • CHECK THIS #BOOK #71084 #Kindle

    How to Become a Scrum Master in 7 Simple Steps (Agile P…

  • CHECK THIS #BOOK #71084 #Kindle

    Scrum, (Mega Pack), For the Agile Scrum Master, Product…

  • Check this out: The FREE SCRUM EBOOK as sold on Amazon. #Scrum #Agile inspired by #Ken Schwaber
  • RT @AgileBelgium: #Agile Tour Brussels 2014: program published, registration open. #atbru #program #published #scrum…
  • Software – Introduction to scrum training and agile training at #approach #scrum #tortillis #organizations
  • RT @ScrumDan: Everyone has been asking me to sell my user Story Cards. #agile #scrum
  • Agile Scrum isn’t a silver bullet solution for s/w development, but it can be a big help. #AppsTrans #HP
  • Read Book : #Kindle #5142 #9: Succeeding with Agile: Software Development Using Scrum


  • Read Book : #Kindle #5142 #1: Scrum Shortcuts without Cutting Corners: Agile Tactics, To…
  • RT @rhundhausen: One blog to inform them all: High quality #Scrum and #Agile posts by high quality practitioners #pr…
  • Here’s how we built the New – Iterative Agile Development Lessons #scrum #agile #iterative
  • RT @BDCEng: Here’s how we built the New – Iterative Agile Development Lessons #scrum #agile #…
  • Read Now #7153 #Kindle

    The Scrum Checklist, For the Agile Scrum Master, Product Owner, …

  • Read Now #7153 #Kindle

    How to Become a Scrum Master in 7 Simple Steps (Agile Project Ma…

  • Read Now #7153 #Kindle

    Scrum, (Mega Pack), For the Agile Scrum Master, Product Owner, S…

  • #Kindle #3: Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addis…
  • Books & Deals >> #32033 #Kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics,…

  • Paperback Scrum: Need a scrum guide: #scrum #agile
  • Lean, Agile & Scrum Conference – Dave Snowden @beyondreqs #cynefin…
  • RT @techXOcafe: Lean, Agile & Scrum Conference – Dave Snowden @beyondreqs #cynefin…
  • RT @gabrielagill53: Making employees happy = #successful company!! @Happy_Melly #scrum #agile #awesome @WIKISPEED
  • Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • RT @yochum: Scrum Expert: Patterns: a New Standard for Scrum #agile #scrum
  • RT @ScrumDan: Everyone has been asking me to sell my user Story Cards. #agile #scrum
  • Agile by McKnight, Scrum by Day is out! Stories via @StratacticalCo @trompouet
  • RT @ClearedJobsDC: Pega Application Developer to join our #EmployeroftheWeek #securityclearance #Agile #Scrum
  • CHECK THIS #BOOK #71084 #Kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics,…

  • RT @rhundhausen: One blog to inform them all: High quality #Scrum and #Agile posts by high quality practitioners #pr…
  • The Best Books : #9516 #Kindle

    Scrum Shortcuts without Cutting Corners: Agile Tactics, …

  • What does the Scrum Master actually do in agile projects? –
  • [QUESTION] The Product Owner Says #NoEstimates From the Team. Now what? #Agile #Scrum #PM #pmot
  • Categories: Blogs

    Does the actual experience at your organisation reflect a supporting culture?

    One of my favourite books that I've read recently is True Professionalism by David H. Maister. In it, he references another of his books, Managing The Professional Service Firm, about asking junior professionals about their experience on work assignments.

    I think this list of questions is generally applicable even outside of professional service firms to assess whether the body language of an organisation actually indicates a supporting culture, independent of what might be claimed:

    Is it usually true that...
    1. When work is assigned, you understand thoroughly what is expected of you
    2. You understand how your tasks fit into the overall objectives of the project, engagement, organisation
    3. You are kept informed about the things that you need to know in order to do your job properly
    4. You receive good coaching to help improve performance
    5. You receive prompt feedback on your work, good or bad
    6. You feel that you are a member of a well-functioning team
    If you flip this around, we can use this as a checklist for when you take on work:
    1. What is expected of me for this work?
    2. How do my tasks fit into overall objectives?
    3. Do I need to know anything else in order to do this job properly?
    4. Who will support me to help improve my performance?
    5. How will I get feedback on whether the work is good or bad?
    6. Who will be part of my team and how will we interact?
    Categories: Blogs

    Open a Github Issue From Slack!

    The other day one of my co-workers opined that it’d be fantastic if we could open a GitHub issue from Slack. Fifteen minutes later the channel got to bask in the awesomeness… of this!

    Read on to discover how to use Zapier (shameless plug: yes, I work on this) to whip this up quickly as well!

    Opening the Issue

    First up, we need to log in to Zapier and set up our first of two Zaps, the one that will create a new issue from Slack.

    Now we’ll select our two services and the desired actions:

    Next up, connect Slack and GitHub to Zapier.

    When we get to step four, we’ll want to setup a custom filter so that we only trigger on Slack messages that contain !gh_issue.

    At step five we’ll want to plug the values in to the GitHub issue from Slack. If you scroll back you’ll remember we used a specific format for our issue:

    !gh_issue title(Junk Issue) description(Junk Issue!) repo(zapier/zapier-infra)

    In Zapier-land, we extract those elements with parenthesis as variables. So when pulling from the trigger we get the raw text and the extracted variables as names like {{text__title}}, {{text__description}}, etc.

    At step six we’ll load some samples.

    Hrmph. All filtered out. Ah! We haven’t actually tried to create an issue from Slack. Let’s go do that now!

    Now we go back to step six and refresh and we should see a new unfiltered sample, of which we can click “See filter sample” to view what will go to GitHub.

    Looks good! Let’s go ahead and click “Test” and check that the GitHub issue was created on GitHub.

    Great! Let’s go ahead and name this Zap!

    But that’s only half the story. It’d also be nice if there was some notification in the channel that it had been created. Not 100% needed, but it would be nice!

    The Webhook

    So we have multiple ways we could approach this here:

    • Create a Zap that polls GitHub issues and alerts the channel of new issues
    • Setup a webhook through Zapier to push new issues instantly to Slack
    • Use the native Slack/GitHub integration on Slack to send the new issue notification

    I’ll admit I didn’t have much luck using the native integration despite wanting it to work as it would have required the least amount of setup. Polling was easy to setup, but it means I can have anywhere from a 1 minute to a 15 minute delay from when I open the issue to when it is published back to Slack. So I opted for the webhook route.

    The Webhook Trigger on Zapier is immensely powerful. You can use it to poll a URL, catch incoming webhooks, and even send webhooks back out to other services. It’s pretty raw but it gets the job done, and it gets it done instantly.

    Like last time, for step one we will select our services: Webhook to Slack!

    In step two, we’ll be given a webhook we can copy and paste to plug it into GitHub. Let’s navigate to GitHub really quick to add it.

    In our repository settings page on GitHub, let’s add a new webhook.

    By default this will fire on all events. We don’t want that, we want each issue.

    This will be grayed out until an event fires, so let’s go back to Zapier and continue working on our Zap.

    On step four, we’ll want add a custom filter so that the Zap will only trigger when issue action is equal to “open”. Otherwise this will fire whenever any activity takes place, such as opening and closing issues.

    The first time through you may get a modal pop up prompting you to go create a new issue when you try to select a field. This is because webhooks are instant and require a user interaction to take place first. So go create an issue (manually or from Slack, it doesn’t matter) and follow the instructions to get it caught by Zapier. Now we can select the field we need and move on. :-)

    At step five it’s time to set up the channel the message will be sent to and what the message will be. I typically prefer to alert the channel of a new issue opened on a repository and then link to it.

    There is also a field for Icon URL that can be used to plug in a specific icon for the Slack bot that broadcasts the message. I usually use a character of ours (Zapbot!) that is similar to Hubot, but Octocat fits well here too!

    Now we’ll test the Zap and if all goes well, name it and set it live!

    Whelp that wraps it up for us… hope you find these Zaps as useful as we have!

    Categories: Blogs

    Sample Page

    Manage Well - Tathagat Varma - Thu, 08/21/2014 - 17:11

    This is an example page. It’s different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this:

    Hi there! I’m a bike messenger by day, aspiring actor by night, and this is my blog. I live in Los Angeles, have a great dog named Jack, and I like piña coladas. (And gettin’ caught in the rain.)

    …or something like this:

    The XYZ Doohickey Company was founded in 1971, and has been providing quality doohickies to the public ever since. Located in Gotham City, XYZ employs over 2,000 people and does all kinds of awesome things for the Gotham community.

    As a new WordPress user, you should go to your dashboard to delete this page and create new pages for your content. Have fun!

    Categories: Blogs

    Hello world!

    Manage Well - Tathagat Varma - Thu, 08/21/2014 - 17:11

    Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

    Categories: Blogs

    News update 2014/08 – 5 Reasons to Kill Time Sheets - Peter Hundermark - Thu, 08/21/2014 - 14:58

    Welcome to our August newsletter. Do you also have a dislike for time tracking? Joanne Perold does, and she explains why in this month’s blog post….more.

    Kanban Foundation TrainingKanban Training

    We still have spaces available on our upcoming Kanban Foundation and Advanced courses. Scrum Sense will once again be teaming up with LKU-accredited Kanban Trainer, Dr. Klaus Leopold of LEANability to present this training.

    Kanban foundational course provides insight and visibility to the “why” of doing things – Dean Harvey, Nedbank Ltd.

    The Applying Kanban (Foundation) and Improving & Scaling Kanban (Advanced) certified courses will be taking place in Sandton on the 20-21 Oct and 23-24 Oct 2014 respectively. We are running a 3-for-2 special offer on both courses, so be sure to secure your place!

    Interesting Links
    • InfoQ has published the first in a series of articles from the short book “Leading Self-Organising Teams” written by Dr. Sigi Kaltenecker & Peter Hundermark. The first article is on “what are self-organising teams?” In the coming weeks this will be followed by “why do we need self-organising teams?” and “what is Leading Self-Organising Teams all about?”. Be sure to follow this series!
    • Dillon Weyer of Scrum Sense has written a blog post on the importance of a defined outcome. The title, “Without an outcome in mind, any road will do!“, perfectly sums up the significance of having an outcome.
    Upcoming Courses

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

    Leading Self-Organising Teams (JHB)
    16-17 Sept 2014
    FNB Conference & Learning Centre, Sandton

    Certified Scrum Product Owner (JHB)
    30 Sept-01 Oct 2014
    FNB Conference & Learning Centre, Sandton

    Applying Kanban (Foundation) – (JHB)
    20-21 Oct 2014
    FNB Conference & Learning Centre, Sandton

    Course schedule and Book Online

    The post News update 2014/08 – 5 Reasons to Kill Time Sheets appeared first on ScrumSense.

    Categories: Blogs