Skip to content


Crouching Supervisor, Hidden File Descriptor Setting

Here’s an interesting problem our team faced last month that was extremely infuriating. We were in the process of launching replacement…

Categories: Blogs

Using Templates in Terraform

We’ve been using terraform at Zapier for over a year now and recently I was adding a new feature and looking over our large collection of…

Categories: Blogs

The Simple Leader: The Hour of Power

Evolving Excellence - Wed, 11/16/2016 - 11:23

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen

O great creator of being grant us one more hour to perform our art and perfect our lives.
– Jim Morrison

When you think about your days, including the weekends, do you see a pattern of times when you’re most productive? Studies have shown that there is an hour or so each day when we’re especially focused and energetic. For many of us, the time is early in the morning (perhaps a relic of our caveman past, when we had to get out early to find food for the family). For others, productivity spikes at other times of the day. Friends and colleagues have told me that their best times to work are mid-morning, afternoon, or even late in the evening.

Over the years, I’ve found that my most productive time, my “Hour of Power,” is from five to six in the morning. Realiz- ing that particular hour is my most productive, I protect it at all cost and schedule nothing during that time, except for the first and most important (and usually most difficult) of my daily Big Three tasks. I take care of other morning activities such as eating, read- ing the paper, going to the gym, and meditation, before five a.m. Otherwise, they get delayed until afterwards. I also prepare to work on the task before my Hour of Power begins so that I don’t sacrifice any of that valuable time trying to figure out where to start.

During the hour, I remove all distractions and focus solely on the task at hand. At the end of it, I mindfully make a decision on whether to continue. I often discover that I have finished the task. Either that, or I am exhausted and need a break before continuing.

Experiment and discover when your Hour of Power is. Then protect it and take advantage of that period of heightened clarity and focus to give a kick to your productivity.

Categories: Blogs

Three Links For Agile Product Development

Learn more about transforming people, process and culture with the Real Agility Program Last week, conversations in the Scrum Facebook Group clamoured around the topic of Agile Product Development and Agile Project Development or Management. To be honest, when I posed a question on the topic I had a hint of its significance but did not have even a glimpse of the depth of this can of worms until many more conversations, online and offline, and research on websites and YouTube on the topic. One respected coach said to me that there may be no bigger issue than this in the Agile industry. Well then, let’s explore it a little bit. Here I’m including three links which Facebook group members recommended. I hope these links may also be useful to other new Product Owners who are grappling with the concept of “no projects” in their work environments. Agile Product Ownership in a Nutshell This is undoubtedly by far the very best Product Owner video I’ve seen to date. It’s just 15 minutes long. The speaker is clear and easy-to-listen to. The graphics are descriptive and simple despite representing complex ideas and systems. I came away from this video with a much more thorough and concrete understanding of the role of Product Owner. Agile Product Management with Scrum: Creating Products that Customers Love,” by Roman Pichler. This book is recommended by a fellow Scrum enthusiast. Amazon describes it in this way,” In Agile Product Management with Scrum, leading Scrum consultant Roman Pichler uses real-world examples to demonstrate how product owners can create successful products with Scrum. He describes a broad range of agile product management practices, including making agile product discovery work, taking advantage of emergent requirements, creating the minimal marketable product, leveraging early customer feedback, and working closely with the development team. While I haven’t had the chance to read it yet myself, I find it reassuring that a renowned author addresses this important topic and offers his valuable insight into the conversation around Product Owner and Project Manager. agile-team-room-example The Software Suicide  On September 09, 2016 a blog post about User stories addressed this very relevant question. The first line states, “User stories can be considered the basic units of work in organisations using an agile approach to product development.” I found this post and this website very useful in understanding the importance of user stories and how these fundamentally shift work process around delivery of value to customers. Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Three Links For Agile Product Development appeared first on Agile Advice.

Categories: Blogs

Leading to Real Agility – Communicate the Vision for Change

Learn more about transforming people, process and culture with the Real Agility Program

Leading an organization to Real Agility requires that you communicate the vision for change throughout your organization.  This video introduces the four key concepts of communicating this vision for change as you and your executive team lead your organization to Real Agility.

The video presents four core concepts:

  1. Continuous communication at every opportunity: every meeting, every phone call, every email, every presentation!
  2. Simplicity of the message: short, jargon-free, concrete.
  3. An emotional component that encourages a change in behaviour.
  4. And urgency!  (A window of opportunity, a competitive threat or an internal problem that needs to be addressed now.)
Leading to Real Agility References

Here are some additional references about how leaders can help their organizations move towards Real Agility by communicating the vision for change:

Please subscribe to our YouTube channel to receive notifications when each new video is published! (There are 15 more videos coming in this series, and more beyond that on other topics!)  You can also find the summary article that helps you find all the videos and additional references here: Leading to Real Agility – Introduction.

Mishkin Berteig presents the concepts in this video series.  Mishkin has worked with leaders for over fifteen years to help them create better businesses.  Mishkin is a certified Leadership Circle Profile practitioner and a Certified Scrum Trainer.  Mishkin is co-founder of BERTEIG.  The Real Agility program includes assessment, and support for delivery teams, managers and leaders.

BERTEIG Real Agility logo - leading to Real Agility

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Leading to Real Agility – Communicate the Vision for Change appeared first on Agile Advice.

Categories: Blogs


Leading Agile - Mike Cottmeyer - Mon, 11/14/2016 - 22:01

my personal kanban


My life just does not work without this. I have always had my general to do and tasks lists and ever famous highlighters to mark them off when they’ve been completed. I’ve always said if it doesn’t get written down, it won’t happen. But it wasn’t until I attended Agile2016 and Catherine Swetel’s Personal Kanban session took me to the next level. It was life changing.

That may sound melodramatic, but let me explain.

I have always had my general to do and tasks lists but Personal Kanban session took me to the next level.

Companies have their own projects, products, and features. Either they end up doing them all half-ass and things fall through the cracks or they do some and end up not meeting all their commitments. Both of these can leave everyone involved feeling not so amazing, as staffing and resources are left on the table or expended inefficiently. It could mean they just can’t do it all, with too many irons in the fire, or the “All” needs to be re-prioritized (much like packing a car.)

In my case, I am the company and have experienced both scenarios. In addition to my work with LeadingAgile, I have engagements with family and friends; I am very active in my church; I volunteer in various community organizations; and I enjoy my lovely me-time as I eat, sleep, drink, be merry, and do whatever else I want with the rest of my disposable time and income. Each of these areas are like business units (noted by the different colored sticky notes.) And each these units have various tasks that I need to do from day to day or week to week (noted by multiple stickies of the same color).

Despite my best intentions, I tend to try to do more than my 24/7 time frame allows. Just like a company, I have a limited number of resources in a day, including time, money, and staffing. I must consider how to utilize each of them efficiently, while also considering that my overall health depends on how all the parts interact with each other around the clock, even while I sleep. (Sleep is a business unit on its own). Sometimes my resources and tasks change from day to day, and I must be flexible and inspect, adapt, add and remove items from my agenda throughout  the week. Otherwise, I get bogged down by feeling unorganized, out of control, flakey, and not the best-version-of-myself.

And that just sucks.

I must be flexible and adapt my agenda for the week, or risk getting bogged down by feeling unorganized, out of control, flakey, and not the best-version-of-myself.

This is what Agile as an industry, Kanban boards, and LeadingAgile’s Transformation Strategy means to me. This is also what a good workshop and coach means to me. My colleague, Derek Huether, has a lot of experience with Kanban and attended that same session at Agile2016 with me. I credit him with helping me fine tune this process until I get comfortable on my own. He also serves as somewhat as an accountability partner for this, something for which I discuss the importance of in the podcast “The Power of Accountability Partnerships.” 

I imagine this might resonate with you, too, whether you are reading this for personal use or for business use as a business owner or employee.  It doesn’t mean that you’re stupid or lazy or even that you have a bad product. It may just mean that you need the right tools and coaching to make you and your product or service shine.

So to say Kanban, a visualization of my commitments, has changed my life is not the overstatement that it appears. I don’t want to just DO out of being a “Yes woman” or overexcitement or obligation, and I don’t want to just be a business for name sake… I want to be an empire that operates and executes at its best and one that you can’t live without.

For me that starts with TO DO. TO DO THIS WEEK. DOING. DONE.

The post TO DO. TO DO THIS WEEK. DOING. DONE… appeared first on LeadingAgile.

Categories: Blogs

Links for 2016-11-13 []

Zachariah Young - Mon, 11/14/2016 - 10:00
Categories: Blogs

Neo4j 3.1 beta3 + docker: Creating a Causal Cluster

Mark Needham - Sun, 11/13/2016 - 14:30

Over the weekend I’ve been playing around with docker and learning how to spin up a Neo4j Causal Cluster.

Causal Clustering is Neo4j’s new clustering architecture which makes use of Diego Ongaro’s Raft consensus algorithm to ensure writes are committed on a majority of servers. It’ll be available in the 3.1 series of Neo4j which is currently in beta. I’ll be using BETA3 in this post.

2016 11 13 09 14 41

I don’t know much about docker but luckily my colleague Kevin Van Gundy wrote a blog post a couple of weeks ago explaining how to spin up Neo4j inside a docker container which was very helpful for getting me started.

Kevin spins up a single Neo4j server using the latest released version, which at the time of writing is 3.0.7. Since we want to use a beta version we’ll need to use a docker image from the neo4j-experimental repository.

We’re going to create 3 docker instances, each running Neo4j, and have them form a cluster. We’ll name them instance0, instance1, and instance2. We’ll create config files for each instance on the host machine and refer to those from our docker instance. This is the config file for instance0:



The only config that changes between instances is dbms.connectors.default_advertised_address which would have a value of instance1 or instance2 for the other members of our cluster.

We can create a docker instance using this config:

docker run --name=instance0 --detach \
           --publish=7474:7474 \
           --publish=7687:7687 \
           --net=cluster \
           --hostname=instance0 \
           --volume /tmp/ce/instance0/conf:/conf \
           --volume /tmp/ce/instance0/data:/data \

We create the network ‘cluster’ referenced on the 4th line like this:

docker network create --driver=bridge cluster

It’s a bit of a pain having to create these config files and calls to docker by hand but luckily Michael has scripted the whole thing for us.

function config {
mkdir -p /tmp/ce/$1/conf
cat > /tmp/ce/$1/conf/neo4j.conf << EOF
function run {
config $INSTANCE
docker run --name=$INSTANCE --detach \
           --publish=$[7474+$HOST]:7474 \
           --publish=$[7687+$HOST]:7687 \
           --net=cluster \
           --hostname=$INSTANCE \
           --volume /tmp/ce/$INSTANCE/conf:/conf \
           --volume /tmp/ce/$INSTANCE/data:/data \
docker network create --driver=bridge cluster
run 0
run 1
run 2

Once we run the script we can run the following command to check that the cluster has come up:

$ docker logs instance0
Starting Neo4j.
2016-11-13 11:46:55.863+0000 INFO  Starting...
2016-11-13 11:46:57.241+0000 INFO  Bolt enabled on
2016-11-13 11:46:57.255+0000 INFO  Initiating metrics...
2016-11-13 11:46:57.439+0000 INFO  Waiting for other members to join cluster before continuing...
2016-11-13 11:47:17.816+0000 INFO  Started.
2016-11-13 11:47:18.054+0000 INFO  Mounted REST API at: /db/manage
2016-11-13 11:47:19.068+0000 INFO  Remote interface available at http://instance0:7474/

Each instance is available at port 7474 but we’ve mapped these to different ports on the host OS by using this line in the parameters we passed to docker run:


We can therefore access each of these Neo4j instances from the host OS at the following ports:

instance0 -> http://localhost:7474
instance1 -> http://localhost:7475
instance2 -> http://localhost:7476

If we open one of those we’ll be confronted with the following dialog:

2016 11 13 12 10 06

This is a bit strange as we explicitly disabled security in our config.

The actual problem is that the Neo4j browser is unable to communicate with the underlying database. There are two ways to work around this:

Connect using HTTP instead of BOLT

We can tell the browser to connect to the database using the HTTP protocol rather than BOLT by unticking the checkbox:

2016 11 13 12 12 24 Update the BOLT host

Or we can update the Bolt host value to refer to a host:port value that’s accessible from the host OS. Each server is accessible from port 7687 but we mapped those ports to different ports on the host OS with this flag that we passed to docker run:

--publish=$[7687+$HOST]:7687 \

We can access BOLT from the following ports:

instance0 -> localhost:7687
instance1 -> localhost:7688
instance2 -> localhost:7689

Let’s try changing it for instance2:

2016 11 13 12 20 29

You might have to refresh your web browser after you change value but it usually updates automatically. We can run the :sysinfo command in the browser to see the state of our cluster:

2016 11 13 12 22 55

And we’re good to go. The full script is available as a gist if you want to give it a try.

Let me know how you get on!

Categories: Blogs

The Simple Leader: Forgive Yourself

Evolving Excellence - Sun, 11/13/2016 - 11:21

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen

Forgive yourself. It sounds simple, but don’t think for a second that it is easy. Getting free from the tyranny of past mistakes can be hard work, but definitely worth the effort. And the payoff is health, wholeness and inner peace. In other words, you get your life back.
– Steve Goodier

We’ve all messed up, even folks like Mother Teresa and Mahatma Gandhi made mistakes. So why do screw-ups burden us so much? The burden can sometimes overwhelm us, change our perspective, create excess caution, and severely impact our leadership effectiveness.

Like everyone, I’ve had some doozies. Some are simply humorous or embarrassing, some I’m ashamed of, and some still make me cringe knowing how close I came to radically changing my life. Fortunately, I’ve always been able to move on fairly easily, sometimes perhaps too much so. As just one small example, nearly twenty years ago, I was hurrying through a store when I came up to an elderly woman blocking a narrow aisle. I moved around her a little too quickly and carelessly, nearly causing her to fall. I immediately felt remorse. To this day, I vividly remember the look on her face and on the faces of others around me, as well as how ashamed I felt. It was a mistake, but I couldn’t change it. I had to forgive myself and learn from the experience.

The past is the past. Nothing is going to change it. To be at peace, you must accept that you will make mistakes. Learn from them, remember them just enough so that you know not to repeat it, make amends if appropriate, and move on. If you knew of someone else that had your past, how would you treat them? Probably with compassion. Do the same to yourself.

Categories: Blogs

Agile Risk Management

Leading Answers - Mike Griffiths - Sat, 11/12/2016 - 16:00
This article aims to dispel the myth that agile projects somehow magical manage risks for us, and outlines a couple of practical tools that can be used to start improving risk management approaches. Agile is Not a Risk Management Approach... Mike Griffiths
Categories: Blogs

Launching a New Product: #1 Question – Is this a Project or a Product?

Learn more about transforming people, process and culture with the Real Agility Program

Recently, it’s come to my attention that a friend is experiencing nearly insurmountable financial hardship. After initially offering to help out by sharing a few food items, I realized that a few items shared once is not enough. This inspired me to consider the idea of sharing food weekly. I decided to create a regular care package of sorts, until she got back on her feet again.

She agreed to pick up a care package from me weekly. And that’s how this social action initiative was born.

Once I knew I’d be doing this weekly, several logistics had to be sorted out. Where was the food coming from? Where would I store the food between pick-ups? When would it be picked up?

Interestingly, I don’t have enough food in my own cupboards to share with someone weekly. Fortunately, I know many others who are like-minded and highly value supporting and helping others so I began to reach out. Within days I had more than seven bags of food to share and it occurred to me that this would be my goal – 7 bags for 7 days. That should get her through the week.

It didn’t take too long for me to see that if I considered myself as the Product Owner of this product – a weekly food package – that there might be valuable Agile concepts and practices which could easily help support the sustainability of this initiative. 

Is this a Project or a Product?”


Immediately, an Agile Coach inspired me to think of this not as a project, but as a product. The main difference, he reminded me, is that a project has a start and an end. A product doesn’t have an end date. It can always improve.

At the beginning, I thought of this as a “project.” You know? A bunch of us getting together with the vision of sharing food weekly. It was our “Food Sharing Project.”

Before long, I realized that was an old way of thinking about work. When I thought about the food package as a product a lot changed. It became easier to see what was needed for this product to be useful to the recipient. The quality of this product became clear.

I also watched this video from Mishkin Berteig which encouraged me to think about the ways in which this package could be run with Scrum. (So far, I am the Product Owner. Now I just need a ScrumMaster and Scrum Team. You never know, maybe this will evolve some day!)

Then I read this article by Mike Caspar which got me thinking about acceptance criteria and the importance of consultation, reflection, learning and planning.

The key learning for me today is that when I think about this service of delivering a weekly care package as a product I see it’s likely it can continue indefinitely, always improving. That really excites me.

It is not a project, but a product and is being organized and delivered using Agile methods.

This is one way that Agile is being used outside of IT with great success.



Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Launching a New Product: #1 Question – Is this a Project or a Product? appeared first on Agile Advice.

Categories: Blogs

Link: Communicate The Vision

Learn more about transforming people, process and culture with the Real Agility Program

This video, newly released on BERTEIG’s YouTube Channel, reminds leaders of their responsibility to communicate the vision to their organization. Check out the 2-minute video for valuable insight into the process.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Link: Communicate The Vision appeared first on Agile Advice.

Categories: Blogs

14 Things Every Agilist Should Know About Kanban

Learn more about transforming people, process and culture with the Real Agility Program


So you are embarking on an Agile transformation. One important thing you need to figure out (and hopefully you have some consultants helping you) is how many Scrum Teams you will need for product development and how many Kanban teams you will need for operations, deployment, support, maintenance, keeping the lights on, etc. Because when you create a bunch of cross-functional teams they will have gaps in their Agile engineering practices and their definition of “done” will have to be limited by several organizational factors. The teams won’t have access to many of the environments and there won’t be enough specialized resources to assign to each team. Plus, the nature of the work coming into the ops and support teams are much more finely grained and varied than user stories in a Sprint Backlog and it’s important that the Scrum teams focus on their products and are not disrupted by every little change request from the business. So you need Kanban teams to do the work that the Scrum Teams can’t do yet as well as the stuff that you don’t want your Scrum Teams to be distracted by.

That’s more or less the popular consensus on the role of Kanban in the Agile community. Some acclaimed thought leaders have even written popular books and blog posts about it. But if one digs a little deeper, one finds that there is much more to Kanban than meets the common agilist’s eye (although clearly this is changing, evidenced by the existence of this piece of writing). So here are the 14 things that I can think of off the top of my head:

  1. The Kanban Method is not about transformation. At least not the radical, deep Satir J-Curve brand of transformation that has been attempted in many organizations. All too often with the radical approach, there is enough resistance to change and enough ensuing chaos for the leaders of the organization to lose patience with the change initiative before the system has a chance to recover.
  2. Moreover (and dangerously), many so-called champions of change are not aware that Satir was a psychotherapist and that her J-Curve method was employed to change the identity of her clients, breaking them down and building them up again. What’s important here is that Satir was a psychology professional working with willing clients to help them transform into the people they wanted to be. This is not the case with most professional knowledge workers. Knowledge workers tend to not be seeking this kind of service from managers and coaches. A more brutal version of this technique has been employed to transform teenagers into deadly soldiers.
  3. Instead of deep J-Curve transformation, the Kanban Method proposes small, rapid J-Curve experiments. This approach to change provokes less resistance, avoids extended periods of thrashing in chaos and the severe testing of leadership patience. Well-designed small J-Curve experiments produce just enough organizational stress to stimulate change without drop-kicking people into deep chaos and despair and forcing the regression of an organization to lower levels of trust and maturity.
  4. The Kanban Method is a management system for the design and evolution of the interdependent services of an organization. Such services are often composed of several Scrum Teams, shared services, managers, senior staff and specialists and are often themselves served by other services. Every service is delivered via a system of stages of knowledge discovery (rather than hand-offs). See more on this here.
  5. The design of a system determines the fitness for purpose, flow of value and quality of the service (as demonstrated by Deming’s Red Bead Experiment). It’s not about high-performance teams. It’s about the performance of the system.
  6. Transparency of the system empowers knowledge workers to self-organize around the work because they understand the system and are trusted to know what to do in order to deliver the service.
  7. Kanban managers are systems managers, not people managers and not coaches.
  8. Team-level Kanban is actually a form of proto-Kanban—still Kanban, but in an immature state, an incomplete rendering of a service delivery system.
  9. A Kanban system is a pull system. The capacity of the system is calibrated for optimum flow. New work enters the system when there is sufficient capacity to absorb the new work without overburdening the system and disrupting flow. Demand is balanced against capacity.
  10. All demand is potentially refutable. When there is capacity in the system to start new work, sources of demand collaborate to determine what is the most important work to start next and the system is replenished.
  11. Deciding what to start next is based on economics—transparent and rational risk assessment.
  12. Once the system is replenished and there is a commitment to deliver the newly-started work, risks are managed with explicit policies such as classes of service, work-in-process limits, pull-readiness criteria, feedback loops and relevant metrics (i.e. not team velocity).
  13. Average lead time from project or feature commitment to completion is a basic metric. Improving the system results in a reduction in both lead time and lead time variability. Delivery forecasts are based on historical lead time data. Deadlines are also managed with lead time data (i.e. deciding when to start something).
  14. All of the above is the responsibility of management. This should leave little management capacity for monitoring individual performance and story point velocity of teams (white bead count). A sign of a mature Kanban system is that managers have improved their behaviour and are focused on improving the system and that knowledge workers are free to self organize around the work as skilled, adult professionals.

If you are interested in the history of the Kanban Method, start here.

Best starter book: Essential Kanban.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post 14 Things Every Agilist Should Know About Kanban appeared first on Agile Advice.

Categories: Blogs

Happy 21st Scrum!

Leading Agile - Mike Cottmeyer - Thu, 11/10/2016 - 15:00

Happy birthday Scrum

Happy 21st Scrum!

Scrum just turned 21, finally old enough to have a beer! Hard to believe, but 21 years ago SCRUM (yes, it was all caps back then) was born. Many thanks to Jeff Sutherland and Ken Schwaber who codified Scrum in 1995 in order to present it at the OOPSLA conference in Austin, Texas via the paper “SCRUM Software Development Process” [1]. For those who may not know it or need a refresher, take at look at the beautiful history of scrum and relish in the amazement of how Jeff and Ken modeled “Scrum” after the 1986 groundbreaking paper “The New New Product Development Game” by Takeuchi and Nonaka [2]. A great read for anyone wanting to understand the core of Scrum.

While birthdays are a time to celebrate what was, it is also important to look at what lies ahead. Dave West, Product Owner at, has an interesting blog on where he sees Scrum headed. Building the bridges to the software craftsmanship and DevOps communities will be one of the key developments to watch for as Scrum reaches for 22. The Agile Alliance, as you might expect, has this to say about Scrum’s 21st.

There will twists and turns as Scrum continues to mature…Recently the Scrum Guide, the de facto bible of Scrum  was updated to include the 5 Scrum Values, it’s first update in 3 years. What we must be careful of is claims such as “Scrum 2.0” or any sort of “new and improved Scrum”. Here is what Ken Schwaber said about any attempt at Scrum 2.0 – “There will be no Scrum Release 2.0…Why not? Because the point of Scrum is not to solve [specific problems of development]… Scrum unearths the problems caused by the complexity and lets the organization solve them, one by one, over and over again.” Well said Ken.

1. “SCRUM Development Process”, Ken Schwaber Advanced Development Methods, 131 Middlesex Turnpike Burlington, MA 01803

2. “The New New Product Development Game”, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, January 1986

The post Happy 21st Scrum! appeared first on LeadingAgile.

Categories: Blogs

Links for 2016-11-09 []

Zachariah Young - Thu, 11/10/2016 - 10:00
Categories: Blogs

Thank You for Making the Inaugural SAFe Summit a Success!

Agile Product Owner - Thu, 11/10/2016 - 05:38

Two short weeks ago, over 400 attendees from 17 countries trekked to Colorado for the first SAFe Summit, making it the largest gathering of its kind to focus exclusively on SAFe and its community of practice. It was an inspiring moment in SAFe’s history, humbling for those of us who have a hand in building the Framework, and one that we hope will have a long-lasting positive impact on those who attended.

summit_ballroomClick to enlarge

Given SAFe’s maturity in the marketplace—now with 80,000 practitioners worldwide—it was important for us to take this major step to support the community, the enterprises they serve, and to provide a platform where people charged with making SAFe succeed in the field could provide indepth feedback to its handlers. Our thought was to hold a ‘big tent’ event for everyone engaged with SAFe—partners, practitioners, instructors, consultants, and enterprise business leaders—because it literally takes a village to support a successful implementation, and that village can only remain healthy and vibrant as long as it collaborates and allows for new ideas and knowledge to flow through it.

day2_openspace_2Open space: this is what community contribution looks like.

As we know from PI Planning, there’s no substitute for coming together under one roof, and the Summit was a stellar example of that. We saw high-energy engagement across the board, new connections forged, and we gained substantive insights from attendees and speakers that wouldn’t have been possible otherwise.

A brief wrap-up can’t do justice to what took place during the four days of the Summit, but here are some themes and topics that we’ll be thinking about and working on in 2017:

Highlights & Themes summit_ryan_martensRyan Martens

Empathy. Our friend Ryan Martens (former CTO of Rally Software) took the stage in a super-hero cape and channeled the great Jean Tabaka when he challenged us to consider the idea that empathy is the missing element in many workplaces. Through this lens, he suggested that you can make technical agility stick by affecting the heart and DNA of the overall business. How do we engage leadership and executives? Through empathy and understanding their context.

Change the heart to change the system.” —Ryan Martens, ‘Agile Hippie’ and Beekeeper

SAFe thrives in a strong learning culture. The four enterprise adopters who shared their SAFe journeys had fascinating stories to tell. Their organizations couldn’t have been more different from each other in terms of size, industry, and development challenges (insurance, pharmaceutical, defense, telecommunications), but they all had something in common: a strong commitment to supporting a learning culture where practitioners are encouraged to continually acquire new knowledge and skills relevant to their role in the implementation.

Long-term coaching is essential, especially dealing with non-software teams who are new to the terminology.” –Yael Man, Elbit

SAFe Fellows Jennifer Fawcett and Inbar Oren happy to get feedback on Essential SAFeSAFe Fellows Jennifer Fawcett and Inbar Oren happy to get Rapid Feedback on Essential SAFe. Click to enlarge.

Essential SAFe. Affectionally called ‘Little-Big SAFe,’ Essential SAFe debuted as a concept earlier this year and was a hot session topic at the Summit. It’s a set of minimal practices without which SAFe might no longer be ‘safe.’ It can provide guidance for organizations that are customizing SAFe but don’t want to stray so far they lose advantages, and it can act as an easy entry point for organizations who aren’t ready for full-on SAFe, but want to start practicing and getting the benefits as soon as possible. We appreciate all the feedback we received at the Summit, and will be introducing a fully-supported version of Essential SAFe in the coming months. In the meantime, you can read more about it here.

A powerful but more accessible perspective to achieving enterprise agility.” —Aspire Consulting

Value Streams—can’t live without ’em. There was much furious note-taking in the two sessions that had to do with value streams. That’s because it’s no secret that the flow of value is entirely dependent on how well you apply and map and analyze your value streams. Without that broader context, your planning, execution, and I&A will always fall short of their potential. As Ryan Martens said, “This little tab changes everything.”

SPCTs and SPCT candidates at the SAFe SummitSPCTs and SPCT candidates at the SAFe Summit

The Making of SPCTs. SPCTs are the only ones who can train and certify SPCs, making them key drivers of the health and well-being of the entire SAFe community. We were happy to see so many SPCTs and SPCT candidates join us for working sessions dedicated to ensuring that the SPCT certification program maintains the most rigorous and meaningful standards for improving the quality of SPCs and SAFe.


New Course SAFe 4.0 Scrum Master

ssm_coverScrum Masters are critical players in a Lean-Agile enterprise and can make all the difference when it comes to an effective SAFe implementation. To that end, we released a new course at the Summit, SAFe 4.0 Scrum Master. This course rounds out a full team curriculum of training including our popular SAFe 4.0 for Teams and SAFe 4.0 Product Manager/Product Owner courses. In addition, for those looking to significantly advance their Scrum Master skills, we recently introduced the SAFe 4.0 Advanced Scrum Master course. The entry-level SAFe 4.0 Scrum Master serves as a prerequisite for that advanced course. View public classes and learn more about the course at

Two New Books from SAFe Authors

new_safe_booksThe Rollout, by SAFe Fellow Alex Yakyma. Based on dozens of real examples, this novel about leadership and building a Lean-Agile Enterprise with SAFe provides a war chest of tools and techniques every change agent and Lean-Agile leader can use to succeed with their SAFe implementation. Learn more at

Tribal Unity, by SPCT Em Campbell-Pretty. Em does a great job of  describing how a Lean-Agile culture can be fostered directly with the ‘team-of-agile-teams,’ the essential building block of enterprise agility. Learn more here.

Downloads, Videos, and 2017 Summit

Go to to find many of the presentations from our Summit speakers, as well as an inspiring collection of on-site video interviews provided by our Summit Media Partner,

To all of our attendees, speakers, exhibitors, partners, volunteers, and facilitators who made this first event so successful, we want to extend our deepest appreciation, especially the four enterprise adopters for sharing their stories of challenges and growth with SAFe.

We’ll be coming together under one roof again next year, so stay tuned for an announcement on dates and location by joining the Summit email list.

Stay SAFe!
—Dean and the entire team from Scaled Agile

Categories: Blogs

Continuous Delivery is More Than Tools: It is a Culture

TV Agile - Wed, 11/09/2016 - 19:47
Some enterprise IT organisations are adopting Continuous Delivery and DevOps thinking that tools is enough to do the job, that all of a sudden they will go faster to market and build quality in because they are automating their existing delivery process. Just throwing tools at the problem is not enough; to be successful, organisations […]
Categories: Blogs

Week-long Sprints Work for Weekly Newsletters

Learn more about transforming people, process and culture with the Real Agility Program

What I like the most about Agile-thinking is the principle of taking action with very little planning. This philosophy of learn-as-you-go creates space and time for the team to experiment with ideas to create a successful product.

For the past year, I have participated in an agile experiment of sorts. Basically, the goal was to write a weekly newsletter. But more specifically, the intention was to create meaningful content to readers of the newsletter which would empower them to continue to make positive change in their organizations by applying Agile methods.

Six weeks after starting the newsletter, I attended my first Certified ScrumMaster (CSM) training in Toronto, Ontario. At first, I thought I could manage the newsletter content and delivery using Scrum. I quickly realized I couldn’t. Even if I viewed myself as a ScrumMaster, I wasn’t working on a Scrum team. There was no Product Owner. It couldn’t be run using Scrum.

However, I realized something essential that I could glean from Scrum and that is the idea of Sprints. I realized right away that if I viewed the creation and delivery of the newsletter in one-week Sprints I likely could be successful. And indeed, this application of a Scrum method was extremely useful.

Thinking about delivering a newsletter in one-week Sprints helped me to think about the smallest amount of content which could be easily and predictably delivered weekly. As my capacity, and the capacity of the team improved, so could the level of complexity also increase.

As the level of complexity increased, the newsletter itself improved in quality.

I would like to write more about how a newsletter can be created and distributed using Sprints and other Agile methods because doing it this way helped me to stay adaptive & flexible as the newsletter was refined.

5 keys for using Sprints to create & distribute a newsletter

  1. Understand “Done Done!” – Before CSM training, the newsletter was “done” when I pressed ‘send’ on my computer. When I better understood the meaning of “Done Done” in a Sprint I changed my thinking and behaviour. When I sent the first draft to be proof-read, this was “Done” and when it was returned to me edited and when I did final revision then it was ready for scheduling. When I pressed “Schedule” then the newsletter was “Done Done.” I would plan to schedule the newsletter three days before it was expected to be released. That gave me three days of  ‘buffer’ to accommodate last-minute changes, if necessary. I was learning to become more Agile.
  2. Learn to Accommodate Last-Minute Changes – If last minutes changes cannot be easily accommodated, then the product delivery is likely not Agile. When I started creating and distributing a weekly product, with the expectation that things could change at any time then I learned to establish a “bare-minimum” which could be produced even if changes occurred. This gave me the ability to be flexible and adaptive and much more Agile.
  3. Be Agile; Don’t Do Agile – When I went to CSM training, I thought I would learn how to do Agile things on my team. When I completed the training and started applying Sprints to the weekly distribution of a newsletter, then I realized I must “Be” Agile in my approach, in my communications, and in my creation of the product. I learned that Agile is really a state of mind and not a “thing” at all. Agile is about continuous action, reflection and planning with an open-mind and a readiness to always learn and grow and change.
  4. Action, Reflection, Planning – Before using one week Sprints, I didn’t give myself enough time to reflect and plan the next Sprint. I had a backlog with enough items to keep me busy for 6 months. My work-in-progress was a nightmare and unmanageable. I had four weeks worth of drafts saved and often got confused between what content was going out when. Establishing a regular weekly cadence helped me take control of this “mess” by just taking small action steps, reflecting on them weekly, and using the learning to plan the next steps. This revolutionized my work.
  5. Prepare For Growth – When a product is delivered successfully with Sprints, it keeps getting better and better. This leads to goals being met and growth happening on the team. In this case, it lead to increasing numbers of subscribers and the establishment of a collaborative team approach to creating and distributing the newsletter. Without Sprints, without an Agile mindset, I’m absolutely certain the goals would not have been achieved and growth wouldn’t have occurred. But with Sprints, things just keep getting better and better every week. I love it!


If you’d like to subscribe to the weekly newsletter I mentioned here, you can do so at this link.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Week-long Sprints Work for Weekly Newsletters appeared first on Agile Advice.

Categories: Blogs

Registration Open for January 2017 Writing Workshops

Johanna Rothman - Tue, 11/08/2016 - 15:23

If you are thinking about writing more or better for next year, take a look at my writing workshops.

I am offering Writing Workshop 1: Write Non-Fiction to Enhance Your Business and Reputation again, so you can learn how to create a daily writing habit, write in small chunks, and start to publish.

I am offering a new writing workshop for people who want to publish more (and be paid for their writing): Writing Workshop 2: Secrets of Successful Non-Fiction Writers.

Take Workshop 1 if you are unsure of your writing. It’s a terrific overview and will help you start with a regular writing habit.

Take Workshop 2 if you are ready to take your writing to the next level. This workshop is about getting paid for your writing, and publishing more often and broadly.

If you’re not sure which workshop is right for you, email me and we can discuss what would work for you.

Super early bird registration ends November 18, 2016 for Workshop 1. Super early bird registration ends November 25, 2016 for Workshop 2.

If you are thinking of writing “more” in 2017, commit now. Make it happen for you.

Categories: Blogs

How Does That Feel?

Agile Tools - Tue, 11/08/2016 - 07:15


“We cannot direct the wind, but we can adjust the sails.”
-Bertha Calloway

I was out racing for the first time in a long time this weekend. I was rusty and sailing on a boat that I was unfamiliar with. Furthermore, I didn’t know anyone on the crew. So I started doing what I like to see others do when racing: I just started talking about what I was seeing happening around me.

“Do you see that boat over there?”

“Hey, look, there’s a puff of wind over there.”

“It looks like the breeze might be filling in from over there.”

I kept that little monologue up, not constantly, but on a fairly regular basis. Just letting others know what I think I’m seeing. At some point during the race, one of the guys looks at me and says, “Tom, I hear you talking about pressure over here, and puffs over there, and I’m not really sure what you are talking about. How do you know there’s really wind over there?”

That’s a great question. And there are a couple of answers. The first answer is that I simply don’t know. I’m really just guessing. It’s the wind that we are talking about after all, and I have no more special insight than the next guy when it comes to divining the nature of the winds. However, I do have a few years of experience, and it turns out that more often than not I tend to get it right. That’s because I’m looking for certain signs on the water that indicate what might be the presence of wind. Something like a telltale pattern of ripples on the surface can indicate a small downdraft…or it could indicate a small school of fish ruffling the water. Now I usually know the difference, but I could be wrong. Trust me, it happens all the time. But I don’t worry about that when I’m racing. I think there is value in sharing all observations about the race course that help to give my team a tactical advantage.

People tend to assume that the person driving the boat, usually a very experienced and capable individual, knows what is best and has a good grip on the situation on the water. Nothing could be further from the truth. It turns out that when you are the skipper, you often have your head stuck in the boat. It’s not the skipper’s fault – it comes with the job. You are trying to steer to the telltales on the sails. You are reacting to pressure on the tiller. You are worried about the next mark rounding. But you can’t look at everything at once. That’s where a crew that can be feeding you that information is very valuable. It also helps if they can be sharing the information with each other. After all, they are no more likely to get it right than anyone else. That’s OK if there are more than one set of eyes looking at the issue. So if I think I see a puff and I call it out, another team member may disagree and point out the school of fish just beneath the surface of the water that I missed. The dialog is self correcting. It’s a constant patter of conversation where we share our impressions, some false, some true, that help us to confirm or deny our race strategy.

The other thing that I frequently do is ask questions like, “how does that feel?” Again, I have lots of experience sailing, but I’ve never sailed on this boat before. So I make changes to the sail trim and then I ask, “Did that help?” Maybe it does, or maybe not.

So not only am I talking about the physical nature of the race course, but I’m also checking in with my crew mates. Now I don’t do this out of any overabundance of concern about their well being. It’s much more practical than that. My actions are impacting their performance. Now maybe they will tell me how they are impacted or maybe they won’t. In fact, it’s often the case that people won’t tell you unless you ask. So I ask a lot. I change the sail trim and I check back with the skipper, “How’s does that feel now? Better? Worse?” I check with the guy trimming the main, “How about you?” Sometimes the answer is just a shrug. That’s fine, that’s good feedback too.

I’ve noticed a curious thing that seems to happen. As you model this behavior, others start to pick it up and do it too. At the start of the race, maybe I’m the only guy who’s talking. Two hours later as we cross the finish line, people are calling out puffs and asking for feedback from each other. People seem to pick up on it pretty quick if it’s useful. And if not, well, then maybe you don’t get invited back. Like I said, I don’t always get it right.

I wonder if the same sort of communication is useful for our development teams? What sort of things should we be talking about? What kind of observations are useful? Where are the ripples on the water for a software development team? I know they are racing – that much is for sure. Is the boss’s door closed? Is Joe late getting into the office? Does that meeting have an agenda? I don’t know, I’m guessing that some of that is water cooler conversation that probably isn’t worth a whole lot. On the other hand, what if I come into the office and mention that one of our biggest competitors just made a key acquisition. That’s going to send a few ripples through the water. What if there is an issue in production? More ripples. Maybe even some waves.

So there may indeed be some utility in sharing your observations about the business, the technology, the current state of the production system. It’s all wind on the water. It’s tactical information that may or may not be useful. But you are definitely better off talking about it.

So What about asking questions? You know like, “How does that feel?” Boy, there’s a question that software guys just absolutely love to get asked. How often are we checking in to get feedback on how our actions have affected those around us. Once a sprint? Of course I can’t wait that long in sailing, because the race is long over by then. The feedback would hardly even be relevant if I waited that long. In order for us to fine tune our performance and work together as a team, we need to be constantly engaging in a dialog that tests our assumptions about the value of the changes we are making. Did that help? How does that feel? It’s a fuzzy sort of qualitative conversation that I’m sure makes some folks uncomfortable. But maybe that’s because we’re using it wrong.

You see, when I ask the helmsman how a change feels, he knows what I’m asking about. He knows I don’t give a damn about his emotional state. I want to know if the boat just got easier to steer. Did the boat speed up? Did it slow down? Perhaps the same should apply to software teams. We need to make sure that we understand how the conversation is intended. When I ask how things feel, it’s not necessarily the touchy feely question you might think. Rather, I might really be interested in how fast you think you are going.

So, how does that feel?

Filed under: Agile Tagged: communication, sailing, talking, wind
Categories: Blogs