Skip to content

Feed aggregator

The Simple Leader: The Two Pillars

Evolving Excellence - Wed, 12/07/2016 - 11:38

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


The majority of Lean transformations will fail. Sorry, that’s just the sad truth. The reason for this failure rate is because Lean has two fundamental pillars that most organizations don’t know about, let alone understand the importance of the second. These two pillars are:

  • Create value from the customer’s perspective through continuous improvement
  • Respect for people

Lean actually differs slightly from the traditional Toyota Production System in the first pillar. Most organizations trying to become “Lean” focus on reducing waste while Toyota promotes creating flow. Although the approach is different, the tools are generally the same and the end goal is still to create value from the perspective of the customer. (One danger of the first approach is that focusing only on waste reduction can lead to an emphasis on cost-cutting instead of true improvement.)

In Lean thinking, there are seven primary forms of waste: unnecessary transport, unnecessary inventory, unnecessary motion, waiting, overproduction, overprocessing, and defects. Others add the waste of human potential, where employees are thought of as just a pair of hands instead of a brain with creativity, knowledge, and experience.

These forms of waste are present in manufacturing as well as office and administrative environments. In fact, you can even find them at home. Did you cook too much food for dinner last night? Did you have to wait in line to take a shower? Did you have to search for hours to find a tool in your cluttered garage? All these are types of waste as defined by Lean principles.

Is important to remember that something is only waste if it does not create value from the customer’s perspective. Identifying the customer and then looking for waste (and value) from the perspective of the customer is far harder than it sounds. Some activities may appear to be waste for one customer and not another. Is a long commute a waste of time? To some it is, to others it is a valuable time to relax and refocus. To add even more complexity, some forms of waste may even be necessary, such as regulatory paperwork. Another example is advertising, an expenditure that doesn’t generally add value for the customer but is necessary to help sustain the business.

Even if a company is good at eliminating waste, it still needs to implement the second pillar—respect for people—if it wants to be successful. Respect for people grew out of Toyota’s concept of “autonomation.” Autonomation means “automation with a human touch.” At Toyota and in TPS, machines aid humans, not vice versa. To this day, when you visit a Toyota factory you will see far more humans than at comparable factories of other automakers. Robots are primarily used in dangerous processes and to lift heavy assemblies.

I have come to believe that respect for people is the most important pillar of Lean. However, because it is the least under- stood (or accepted), it is often the primary reason why most Lean transformations fail. Companies focus on eliminating waste and do not emphasize having respect for people, which causes the whole system to collapse. People are the core value-creators of a Lean organization, something many companies do not understand. Toyota is known for saying “we develop people before we make cars.”

Respect for people takes many forms. First, it aims to create an environment for employees where ideas, knowledge, creativity, and experience are valued. Traditional accounting practices measure the cost of the pair of hands, but do not measure the value of experience and creativity in the brain attached to the pair of hands. The lack of a defined value offset is why traditional accounting drives decisions to move factories to countries with lower labor costs, even if hundreds or thousands of experienced, creative people are replaced by even more people with less knowledge.

Respect for people also applies to customers. Every customer is considered to be very important, and their problems are taken seriously. This is part of why Toyota failed with their series of recalls in 2009 and 2010. Instead of holding to a strong culture of respect for its customers, the company tried to play down the stuck accelerator problem for years before the negative perception and press became too great. Imagine how much different those years—and the resulting financial and reputational costs—would have been if Toyota had publicly treated each incident as being extremely serious.

Respect should also be promoted among a company’s suppliers and community, which is why a more accurate translation of Toyota’s “respect for people” is really “respect for humanity.” Engaging the entire value stream and business environment in continuous improvement efforts and knowledge development can pay huge rewards in terms of trust, ideas, and support.

Lean’s reputation is not always one of having respect for people. When Womack and Jones wrote their book in 1990, they could not have anticipated the problems associated with “Lean” rhyming with “mean.” Not a day goes by without some reference to a “Lean and mean” organization. This is a misperception. Real Lean is definitely not mean to the people implementing it.

Real Lean companies leverage productivity improvements to capture new business, which allows them to keep the people impacted by those improvements. Some Lean companies go so far as to pledge that there will be no layoffs due to Lean efforts. This is often necessary to get buy-in for what can appear to be job-threatening improvement programs. And Lean companies like Toyota are generally not unionized simply because the employees are already treated with respect and often paid better than at comparable organizations.

At its most fundamental level, Lean is about enabling people to create improvements that add value for the customer. Leadership is also about people, including ourselves. Together, this is the foundation for our exploration of how Lean can help transform personal and professional leadership.

Categories: Blogs

Transforming Good Teams Into Awesome Ones

Scrum Expert - Wed, 12/07/2016 - 11:33
This is not a talk about teams. This is a talk about you and your role in developing a great team. No matter whether you are a Scrum Master, Project Manager or CTO, at least part of your job is to help your team or teams grow. In order to make this happen you need to work on two levels: The Zen Level and The Operational Level. The Zen Level is mostly about maintaining the right attitude. The Operational Level is mostly about taking the right steps. We will share our experience from Agile transformations we worked on recently, success and failure stories and steps we make while working with the teams. Join us to master the two levels while working with your people. Beware, they may become an awesome team that hardly needs you to succeed. Video producer:
Categories: Communities

Smaller User Stories Podcast

Agile Learning Labs - Wed, 12/07/2016 - 11:10

I recently had a conversation with Dave, over at the Mastering Business Analysis podcast, about splitting big user stories down into smaller stories. The interview was a lot of fun and it’s available now. You can get it direct from the Mastering Business Analysis website, or point your podcatcher at one of these links:

You can also read about splitting user stories at


Chris Sims

Categories: Companies

Download G2 Crowd’s report on the 22 best project management tools

TargetProcess - Edge of Chaos Blog - Tue, 12/06/2016 - 17:59


G2 Crowd has released its “Best Project Management Software” report for summer 2016. This report examines the 22 most popular project management systems and provides features comparisons for each, as well as an extended profile of each tool. The report is based on reviews written by over 2180 authenticated business professionals.  

Thanks to reviews from our users, Targetprocess is ranked as a leader this year and won in the customer satisfaction category.  

We'd be happy to share this report with you. Just enter your email in the form below, and we’ll mail you a link so you can see for yourself.



Thank you. We’ll send a link to the report to your email address in a few minutes.

“Targetprocess allows our organization to manage multiple projects, with each project utilizing a different methodology and workflow. Targetprocess provides a high level of configurability and a robust suite of features that set it apart from every other product that I've found. Not only does Targetprocess deliver a powerful project management solution, their support team is second to none. I've never dealt with a more responsive, knowledgeable, and professional group of product support specialists. Extremely stable product.”

“We switched to Targetprocess after a lot of research and then a trial of 3 different tools. We were primarily looking to move to a hosted solution but wanted to ensure that whatever we moved to could fit with how we worked rather than make us work around the tool. Targetprocess was by far the best and I have to say that it feels like a tool designed to favour flexibility and customisation rather than trying to oversimplify everything and make assumptions about how you work.

The cross project capabilities were really the clincher for us as we have a large number of interdependent projects and most tools don’t handle this very well at all.”

Categories: Companies

A3 Templates for Backbriefing and Experimenting

AvailAgility - Karl Scotland - Tue, 12/06/2016 - 13:59

I’ve been meaning to share a couple of A3 templates that I’ve developed over the last year or so while I’ve been using Strategy Deployment. To paraphrase what I said when I described my thoughts on Kanban Thinkingwe need to create more templates, rather than reduce everything down to “common sense” or “good practice”. In other words, the more A3s and Canvases there are, the more variety there is for people to choose from, and hopefully, the more people will think about why they choose one over another. Further, if people can’t find one that’s quite right, I encourage them to develop their own, and then share it so there is even more variety and choice!

Having said that, the value of A3s is always in the conversations and collaborations that take part while populating them. They should be co-created as part of a Catchball process, and not filled in and handed down as instructions.

Here are the two I am making available. Both are used in the context of the X-Matrix Deployment Model. Click on the images to download the pdfs.

Backbriefing A3

Backbriefing A3

This one is heavily inspired by Stephen Bungay’s Art of Action. I use it to charter a team working on a tactical improvement initiative. The sections are:

  • Context – why the team has been brought together
  • Intent – what the team hopes to achieve
  • Higher Intent – how the team’s work helps the business achieve its goals
  • Team – who is, or needs to be, on the team
  • Boundaries – what the team are or are not allowed to do in their work
  • Plan – what the team are going to do to meet their intent, and the higher intent

The idea here is to ensure a tactical team has understood their mission and mission parameters before they move into action. The A3 helps ensure that the team remain aligned to the original strategy that has been deployed to them.

The Plan section naturally leads into the Experiment A3.

Experiment A3

Experiment A3

This is a more typical A3, but with a bias towards testing the hypotheses that are part of Strategy Deployment. I use this to help tactical teams in defining the experiments for their improvement initiative. The sections are:

  • Context – the problem the experiment is trying to solve
  • Hypothesis – the premise behind the experiment
  • Rationale – the reasons why the experiment is coherent
  • Actions – the steps required to run the experiment
  • Results – the indicators of whether the experiment has worked or not
  • Follow-up – the next steps based on what was learned from the experiment

Note that experiments can (and should) attempt to both prove and disprove a hypothesis to minimise the risk of confirmation bias. And the learning involved should be “safe to fail”.

Categories: Blogs

How I lost my job by implementing Agile #sgza

Growing Agile - Tue, 12/06/2016 - 12:34
This was an open, honest and powerful talk by Jan Jaap Cannegieter. He told the story of how he attended AgileTD and realised that he was putting people into boxes as a Vice President and that to be truly agile he needed to stop that. The end result? He got fired! It’s all good now […]
Categories: Companies

Agendashift, Cynefin and the Butterfly Stamped

AvailAgility - Karl Scotland - Mon, 12/05/2016 - 18:08

The butterfly who stamped

I’ve recently become an Agendashift partner and have enjoyed exploring how this inclusive, contextual, fulfilling, open approach fits with how I use Strategy Deployment.

Specifically, I find that the Agendashift values-based  assessment can be a form of diagnosis of a team or organisation’s critical challenges, in order to agree guiding policy for change and focus coherent action. I use those italicised terms deliberately as they come from Richard Rumelt’s book Good Strategy/Bad Strategy in which he defines a good strategy kernel as containing those key elements. I love this definition as it maps beautifully onto how I understand Strategy Deployment, and I intent to blog more about this soon.

In an early conversation with Mike when I was first experimenting with the assessment, we were exploring how Cynefin relates to the approach, and in particular the fact that not everything needs to be an experiment. This led to the idea of using the Agendashift assessment prompts as part of a Cynefin contextualisation exercise, which in turn led to the session we ran together at Lean Agile Scotland this year (also including elements of Clean Language).

My original thought had been to try something even more basic though, using the assessment prompts directly in a method that Dave Snowden calls “and the butterfly stamped“, and I got the chance to give that a go last week at Agile Northants.

The exercise – sometimes called simply Butterfly Stamping – is essentially a Four Points Contextualisation in which the items being contextualised are provided by the facilitator rather than generated by the participants. In this case those items were the prompts used in the Agendashift mini assessment, which you can see by completing the 2016 Agendashift global survey.

This meant that as well as learning about Cynefin and Sensemaking, participants were able to have rich conversations about their contexts and how well they were working, without getting stuck on what they were doing and what tools, techniques and practices they were using. Feedback was very positive, and you can see some of the output in this tweet:

Four of the #Agendashift #Cynefin results from tonight’s #AgileNorthants meetup.

— Karl Scotland (@kjscotland) November 29, 2016

I hope we can turn this into something that can be easily shared and reused. Let me know if you’re interested in running at your event. And watch this space!

Categories: Blogs

Xanpan – Team Centric Agile Software Development

Scrum Expert - Mon, 12/05/2016 - 16:40
At the beginning of his book, Allan Kelly describes Xanpan as both a method and a philosophy, his philosophy on how software is, or should be, created, and how Agile works, or should work. If Xanpan is basically a mix of XP (eXtreme programming) and Kanban, it contains ideas and techniques of other Agile and Lean approaches, focusing on how teams should work together to deliver better software and value. The book explains how to apply the Xanpan principles and perspective on all the aspects of Agile software development like planning and estimating. It proposes also a set of technical and non-technical practices that should help teams. Xanpan offers also a tool to plan beyond the next two-week iteration, giving teams a perspective of what would be done in the next quarter and even further with roadmaps. One of the most interesting part of the book is the final appendix where Allan Kelly discusses his own definition of software quality and presents the “quality onion”. With this book Xanpan, Allan Kelly presents his own very personal and interesting perspective on Agile software development. This is a book that I will recommend to every ScrumMaster, Agile Coach or software developer that thinks that improving the software development process of a team is more about doing the right changes to the current process than blindly adopting a new approach. Reference: Xanpan – Team Centric Agile Software, Allan Kelly, 200 pages, Web site: Quotes Saying Xanpan is team centric also helps [...]
Categories: Communities

The Break-Up

Leading Agile - Mike Cottmeyer - Mon, 12/05/2016 - 15:00

True Story.

It was a painful breakup. I thought things were going fine, but “it’s not you” she said “it’s me”…. and just like that, our relationship was over.

I really didn’t see it coming. We have been working together for a long time now.

Really? Really, I said. You no longer need QA?

She went on to explain that as her team has gotten better and better at building software, the whole team has taken more ownership of quality. They are on a pretty consistent cadence now and have working tested software ready to ship every two weeks…which is just about the time it used to take to just get through a QA testing cycle. “We are just moving way too fast for that nowadays” she said.

At first I was incredulous. Everyone needs quality assurance! QA is an essential role! You can’t just pump out code and hope it is good enough. The customers would crucify us for that. At first, I thought what she was saying was ridiculous, but the more she explained it, the more it started to make sense. Her team had started Test Driving development a couple of years ago and now they have really high levels of confidence in the entire codebase. “It’s a team quality thing” she said.

I knew this team was good. The code is both Clean and SOLID.

Their quality metrics are on par with any other team. They consistently produce 90% automated test code coverage, including code branches. Code reviews made sure that everything was covered, and they had automated jobs that broke whenever they decreased that coverage. Ultimately, they have virtually no defects that get into Production; some of the best code there is. They also have automated acceptance tests, UI tests and load and performance tests. They have pretty much automated the entire testing pyramid.

Testing Pyramid

Test Driven Development (TDD) was just the start though. Soon after the programmers were test driving, the QA folks started automating UI tests in Selenium. To learn how, they had been pairing with programmers and their relationships in the team were the best of any of my QA teams. After that, they started using CucumberJVM to build behavior tests with the Business Analysts and the Product Owners. The pace of development with this team was better than any other team and I had pretty much let the team run on autopilot because they never seemed to have the same kind of problems
the other teams have.

“We no longer have a QA verified cycle” she said. “We have renamed it to ‘Team Verified, because the whole team does testing before we demo it”. She went on. “We’ve also taken ownership of exploratory testing. The whole team does exploratory testing every week and this has really been a place where the QA folks have been a big help.”

“So you do need us” I said. “Oh yes” she said, “your people are great, but let me explain. We still want all the quality experts we can get. As long as they are committed to the team, are committed to continuing their learning, and stay with the team every day”.
She looked right at me and said, “What we don’t need is all the management oversight we used to have”.

I was beginning to understand. I realized that she still wanted quality. In fact, she was more dedicated to quality than just about any other team in the organization and we are a huge organization. She was advocating for a level of quality the other teams could only hope to duplicate.

She went on to say, “we’d like to keep some of your team members if we can”. “What do you mean?” I said. She went on…”Most of your team members have embraced the changes we have introduced. They love test automation, learning and the collaborative nature of how we produce quality now. And those folks have a place on our team.” She went on, “The QA folks really took a leadership role with exploratory testing. We want to keep them because they see things differently. They look for anomalies and edge cases and they really help the team round out all the aspects of testing that we need.”

Granted, this team has really taken agile adoption and self-organization seriously. They really epitomize teamwork. They do not behave like an assembly line, passing work from one role to another. They’ve eliminated a lot of the limitations of specific roles in the team room through organized cross-training and pairing. For just about any task, most anyone can pair with someone if not complete the task themselves outright.

“But we move fast now, as a team” she said. “And I guess what I’m saying, is that we want to keep your folks on the team and…well, there’s still a lot more that I can go into, but the short answer is…We just don’t need a QA Lead anymore.”

I was crestfallen. The breakup wasn’t painful from her perspective. The pain was all in my head. It was just a matter of my realization that self-organizing teams don’t need as much management as a traditional team. The whole team owns quality now, and, I suppose, in the long run, that’s going to turn out to be a really good thing.

The post The Break-Up appeared first on LeadingAgile.

Categories: Blogs

The Tweets You Missed in November

Sonar - Mon, 12/05/2016 - 12:05

Here are the tweets you likely missed last month!

"SonarQube 6.x series: Focused and Efficient", by @bellingard

— SonarQube (@SonarQube) November 3, 2016

SonarQube JavaScript 2.18: 10 new rules and significant improvements to the type-based analysis, see

— SonarQube (@SonarQube) November 21, 2016

SonarLint for IntelliJ 2.4 hides false-positive and won't-fix issues in connected mode.

— SonarLint (@SonarLint) November 17, 2016

SonarLint for Eclipse 2.3 hides false-positive and won't-fix issues in connected mode.

— SonarLint (@SonarLint) November 28, 2016

SonarLint for Visual Studio 2.8 Released with even more powerful path-sensitive dataflow engine see @VisualStudio

— SonarLint (@SonarLint) November 29, 2016

Categories: Open Source

Agile on the Beach 2017 Call for Speakers

Scrum Expert - Mon, 12/05/2016 - 10:38
Agile on the Beach is a two-day conference on Scrum and Agile approaches that Falmouth in Cornwall (UK) on 6th and 7th July 2017. The call for speaker has just been opened and submissions should be made by 4 January 2017. The Agile on the Beach 2017 conference will focus Agile working, software creation and delivery, teams, practice and new business thinking. These themes will be organized as six tracks, some on different days: * Software delivery: including programing, testing and operations * Team Working, e.g. culture, personnel management, self-organization, leadership * Agile Practices, e.g. agile basics, applying agile tools and methods, writing user stories. * Product Design, e.g. user experience, front end design * Product Management, e.g. requirements gathering, the product manager role * Business, e.g. applying agile beyond software Get more information about Agile on the Beach 2017 Call for Speakers on
Categories: Communities

Kubernetes: Simulating a network partition

Mark Needham - Sun, 12/04/2016 - 14:37

A couple of weeks ago I wrote a post explaining how to create a Neo4j causal cluster using Kubernetes and … the I wanted to work out how to simulate a network partition which would put the leader on the minority side and force an election.

We’ve done this on our internal tooling on AWS using the iptables command but unfortunately that isn’t available in my container, which only has the utilities provided by BusyBox.

Luckily one of these is route command which will allow us to achieve the same thing.

To recap, I have 3 Neo4j pods up and running:

$ kubectl get pods
neo4j-0   1/1       Running   0          6h
neo4j-1   1/1       Running   0          6h
neo4j-2   1/1       Running   0          6h

And we can check that the route command is available:

$ kubectl exec neo4j-0 -- ls -alh /sbin/route 
lrwxrwxrwx    1 root     root          12 Oct 18 18:58 /sbin/route -> /bin/busybox

Let’s have a look what role each server is currently playing:

$ kubectl exec neo4j-0 -- bin/cypher-shell "CALL dbms.cluster.role()"

$ kubectl exec neo4j-1 -- bin/cypher-shell "CALL dbms.cluster.role()"

$ kubectl exec neo4j-2 -- bin/cypher-shell "CALL dbms.cluster.role()"


Slight aside: I’m able to call cypher-shell without a user and password because I’ve disable authorisation by putting the following in conf/neo4j.conf:


Back to the network partitioning…we need to partition away neo4j-2 from the other two servers which we can do by running the following commands:

$ kubectl exec neo4j-2 -- route add -host neo4j-0.neo4j.default.svc.cluster.local reject && \
  kubectl exec neo4j-2 -- route add -host neo4j-1.neo4j.default.svc.cluster.local reject && \
  kubectl exec neo4j-0 -- route add -host neo4j-2.neo4j.default.svc.cluster.local reject && \
  kubectl exec neo4j-1 -- route add -host neo4j-2.neo4j.default.svc.cluster.local reject

If we look at the logs of neo4j-2 we can see that it’s stepped down after being disconnected from the other two servers:

$ kubectl exec neo4j-2 -- cat logs/debug.log
2016-12-04 11:30:10.186+0000 INFO  [o.n.c.c.c.RaftMachine] Moving to FOLLOWER state after not receiving heartbeat responses in this election timeout period. Heartbeats received: []

Who’s taken over as leader?

$ kubectl exec neo4j-0 -- bin/cypher-shell "CALL dbms.cluster.role()"

$ kubectl exec neo4j-1 -- bin/cypher-shell "CALL dbms.cluster.role()"

$ kubectl exec neo4j-2 -- bin/cypher-shell "CALL dbms.cluster.role()"


Looks like neo4j-0! Let’s put some data into the database:

$ kubectl exec neo4j-0 -- bin/cypher-shell "CREATE (:Person {name: 'Mark'})"
Added 1 nodes, Set 1 properties, Added 1 labels


Let’s check if that node made it to the other two servers. We’d expect it to be on neo4j-1 but not on neo4j-2:

$ kubectl exec neo4j-1 -- bin/cypher-shell "MATCH (p:Person) RETURN p"
(:Person {name: "Mark"})

$ kubectl exec neo4j-2 -- bin/cypher-shell "MATCH (p:Person) RETURN p"


On neo4j-2 we’ll repeatedly see these types of entries in the log as its election timeout triggers but fails to get any responses to the vote requests it sends out:

$ kubectl exec neo4j-2 -- cat logs/debug.log
2016-12-04 11:32:56.735+0000 INFO  [o.n.c.c.c.RaftMachine] Election timeout triggered
2016-12-04 11:32:56.736+0000 INFO  [o.n.c.c.c.RaftMachine] Election started with vote request: Vote.Request from MemberId{ca9b954c} {term=11521, candidate=MemberId{ca9b954c}, lastAppended=68, lastLogTerm=11467} and members: [MemberId{484178c4}, MemberId{0acdb8dd}, MemberId{ca9b954c}]

We can see those vote requests by looking at the raft-messages.log which can be enabled by setting the following property in conf/neo4j.conf:

$ kubectl exec neo4j-2 -- cat logs/raft-messages.log
11:33:42.101 -->MemberId{484178c4}: Request: Vote.Request from MemberId{ca9b954c} {term=11537, candidate=MemberId{ca9b954c}, lastAppended=68, lastLogTerm=11467}
11:33:42.102 -->MemberId{0acdb8dd}: Request: Vote.Request from MemberId{ca9b954c} {term=11537, candidate=MemberId{ca9b954c}, lastAppended=68, lastLogTerm=11467}

11:33:45.432 -->MemberId{484178c4}: Request: Vote.Request from MemberId{ca9b954c} {term=11538, candidate=MemberId{ca9b954c}, lastAppended=68, lastLogTerm=11467}
11:33:45.433 -->MemberId{0acdb8dd}: Request: Vote.Request from MemberId{ca9b954c} {term=11538, candidate=MemberId{ca9b954c}, lastAppended=68, lastLogTerm=11467}

11:33:48.362 -->MemberId{484178c4}: Request: Vote.Request from MemberId{ca9b954c} {term=11539, candidate=MemberId{ca9b954c}, lastAppended=68, lastLogTerm=11467}
11:33:48.362 -->MemberId{0acdb8dd}: Request: Vote.Request from MemberId{ca9b954c} {term=11539, candidate=MemberId{ca9b954c}, lastAppended=68, lastLogTerm=11467}

To ‘heal’ the network partition we just need to delete all the commands we ran earlier:

$ kubectl exec neo4j-2 -- route delete neo4j-0.neo4j.default.svc.cluster.local reject && \
  kubectl exec neo4j-2 -- route delete neo4j-1.neo4j.default.svc.cluster.local reject && \
  kubectl exec neo4j-0 -- route delete neo4j-2.neo4j.default.svc.cluster.local reject && \
  kubectl exec neo4j-1 -- route delete neo4j-2.neo4j.default.svc.cluster.local reject

Now let’s check that neo4j-2 now has the node that we created earlier:

$ kubectl exec neo4j-2 -- bin/cypher-shell "MATCH (p:Person) RETURN p"
(:Person {name: "Mark"})


That’s all for now!

Categories: Blogs

The Simple Leader: Do Something Different

Evolving Excellence - Sun, 12/04/2016 - 11:35

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

Unless you try to do something beyond what you have already mastered, you will never grow.
– Ralph Waldo Emerson

Acquiring new knowledge and perspectives helps you grow within your general area of comfort or interest. To really grow, you need to stretch yourself outside of that comfort zone by learning or experiencing something completely different. In addition to acquiring the new skill, knowledge, or experience, you also create confidence in your ability to break boundaries. This can help you awaken to your true meaning.

A couple years ago, I came across an article by Heather Kelly on (“Mark Zuckerberg’s Bizarre New Self-Improvement Goal”) about how Facebook’s Mark Zuckerberg sets an annual “challenge” goal:

Every year, the Facebook CEO sets some sort of challenge for himself. In 2009, he vowed to wear a tie to work every day to show he was serious about Facebook’s growth (and possibly get a break from the signature T-shirt and hoodie he wears to every public event). In 2010, he tried to learn Mandarin.

The annual challenges sometimes make headlines, most famously in 2011 when Zuck vowed to eat animals only if he had killed them himself. That pronouncement led to a mixture of backlash and praise from animal-rights activists.

This year [2012], the famously introverted Zuckerberg is seeking out more conversations with actual humans.

Seeking out more human interaction as a goal seems a bit odd until you think about the world that the young founder of Facebook lives in: a rarified air of groupies, yes-men, analysts, and press types. Interacting with “actual humans” is probably a challenge. Why is that bizarre? I applaud him for it. In 2013, Zuckerberg’s goal was to meet someone new every day; in 2014, he challenged himself to write one thank you note each day; and in 2015, he read a new book every other week.

A key outcome to these challenges is that he learns something new and (often) unexpected. Trying to learn Mandarin taught him that he didn’t listen well, and a year of killing animals made him consider becoming vegetarian. Zuckerberg’s 2012 goal, to converse with humans, helped him understand the personal side of immigration issues.

The reason Zuckerberg’s “bizarre” goals resonated with me is because I have had similar goals for well over twenty years. At first they weren’t true goals—they were just something fun to do. But for the last decade or more, the goals have been formal, with a process for identifying, executing and reviewing progress.

Over the past couple decades, I learned to scuba dive, windsurf, and code HTML by hand. I wrote a book, rebuilt a yellow 1973 Triumph Spitfire, became a vegetarian (rather, a “pescaterian”), skied in five different European countries over six days, started a blog, and ran a full marathon. Toward the end of each year, I identify something to try that is different, unique, or challenging, and develop a plan to dive into it. During the next year, I execute, reflect, and adjust based on my observations. Sound familiar? Plan, do, study, act.

In 2012, my goal was to leave a great job as president of a medical device company and take more control of my life. I notified the board in January, executed a transition plan for myself and the company, and, like a skydiver jumping out of a perfectly good airplane, left full-time secure employment on December 31st. I’m loving it, and the move also created positive secondary effects for the company: a great new Lean leader was developed to replace me and the company got a fresh infusion of Lean energy.

One of my other recent goals—related to this book—was to learn about and understand Buddhism, something I’d bumped into during my trips to Asia and also while living in California. I read books about it, talked to a lot of people, and in a sense, went to the gemba by spending a few weeks in Bhutan and Nepal. I learned about Zen’s history, how it evolved and split into the Theravada and Mahayana traditions, how Mahayana then evolved into Pure Land, Tibetan, and the Zen tradition that’s increasingly popular in the West. What I learned changed how I understood myself.

My goal this year is to read an important work of literature from each of the major ethnic groups or cultures: Latin American, Chinese, Indian, African, and so forth. My annual exploration takes me down some interesting and often unexpected paths, teaching me new thoughts, knowledge, or activities.

The point is that many people say they “think outside the box” but most do not actually explore outside the box. Relatively few people live with an open mind, and even fewer create goals to stretch themselves. Most people find it very difficult to put processes and hansei in place (Zuckerberg apparently does) because it is easier to talk than to act.

I can’t claim credit for knowingly thinking outside the box, especially initially. I sort of fell into doing it. But trying new things has broadened my perspectives by challenging my old perceptions and beliefs. It has deepened my understanding of the world we live in and taken me to interesting places—both physical and spiritual—that I previously wasn’t even aware of.

How will you explore out of the box next year? Perhaps more importantly, how will you ensure you actually do it, and why?

Categories: Blogs

Keeping Remote Teams Cohesive, Part 1: 6 Steps to Hiring Remote Employees

Now more than ever, companies are experimenting with allowing their employees to work from home. Some companies...

The post Keeping Remote Teams Cohesive, Part 1: 6 Steps to Hiring Remote Employees appeared first on Blog | LeanKit.

Categories: Companies

Top 10 Secrets of Agile Transformation with Michael Sahota

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

I dutifully watch Scrum Alliance’s webinars whenever they offer something I want to learn about, so I recently attended Michael Sahota’s “Top Ten Secrets of Agile Transformation.”

Sahota is a bit of an Agile guru, and well-respected in the community. He founded the Toronto Agile Community, and can be seen at Scrum Alliance gatherings everywhere. He also facilitates a Certified Agile Leadership course. You can learn more about Sahota by going to his website

The webinar he conducted was fascinating, because by the time he went from #1 to #10, I realized his “secrets” were very simple, and that one could start with #10 and work backwards to #1 and learn the same things.

By simple I mean his points were clearly articulated and comprehensive.

Before enunciating his secrets Sahota started with the idea that “Culture is the #1 Challenge with Agile.” He asked, “What are we (agilists) doing to create resistance to a change of culture in an organization?” Mindset, he averred, is more important than the practice of Agile – by which he referenced creating safe and trusting relationships, engaging with others, promoting continuous learning, innovation and so on. On a continuum line with “practices” on one end and “mindset/culture” on the other, he urged practitioners to find a balance between the two.

And now for the count-up:

Secret #1 – Clarify the purpose of bringing in an Agile coach by asking “why?” Usually the answers have to do with improving the quality of a product and encouraging more collaboration.

Secret #2 – Focus on organizational goals (and drop the word “Agile”). If the goals are clear, as those articulated above, one can drop the Agile initiative and try another. Agile is not the goal, but focussing on doing and being Agile can set up the wrong expectations. You may say, “Of course we will likely use Agile to help us achieve the organization’s goals,” but remember that Agile cannot be the goal!

Secret #3 – Focus on growth (and drop “transformation”). The idea of transformation is that it is a painful process. It also implies an end point: one is transformed. The idea of growth is more natural, and transformation is really about creating healthy change and growth. It is ongoing.

Secret #4 – Increase awareness of the global context. Global trends mean that an organization must be growing to survive. A lot of organizations do not know how to read their engagement surveys, or don’t even have them. People’s talents are wasted when engagement is low, which leads to massive financial waste. Millennials demand change – will not seek to work in an organization that’s regressive or stagnant. An agile enterprise is resilient and anti-fragile. How well is an organization set up to thrive in the future?

Secret #5 – Increase awareness of organizational context – what’s happening in an organization? However, resist telling leaders that their organization is broken. Start with humility and compassion, and then show leaders that there is a lack of engagement by their members by reading the survey. It’s not about blame – have the leaders acknowledge this and say what they want to do about it. What difficult conversations are needed here? The coach must stand in the truth of what’s happening, listen and understand. Be real.

Secret #6 – Clarify the focus of the initiative. Is more time spent on tactical initiatives (as in, how do we work?), in strategic initiatives (what do we want to achieve?), or in cultural concerns (who do we want to be?)? Discuss what percentage of time is needed to spend on culture in order to have a bright future.

Secret #7 – Build a shared understanding of what culture is. Culture has to do with both consciousness (or energetic property) and structures. Consciousness includes identity, values, beliefs, and the unwritten rules and norms in an organization. It includes values such as safety, trust, people being valued… Structure (practices) and consciousness (culture) co-exist together and are inter-dependent.  Refer to the Agile Manifesto: people over process. – focus on structures without consciousness cannot succeed.

Secret #8 – Clarify the leaders’ role in growing. The consciousness of the leadership is most important. New organizational behavior requires new leadership behavior. Growth requires leaders go first! How do we invite them to go first?

Secret #9 – Honour the leaders’ freedom to choose. Do they wish to work on something tactical? Cultural? A coach must let go of what he or she wants. We cannot coerce people into believing what we believe.

Secret #10 – Growth can happen anywhere.You, as an individual, are the limit for growth.

Sahota suggests creating a culture-bubble in which consciousness and safety can be grown. In this last point he quotes Gandhi: “Be the change that you want to see in the world.”

I am aware that in the 45 minutes of the webinar, Sahota went through each point relatively quickly. Each one in itself provides room for reflection. For me, the fact that the tenth “secret” puts the onus on each individual to grow is telling; if we change, we can help those around us in their transformation. But that requires extra-consciousness, I think, and humility. Overall, Sahota points to values and culture within and without as the key.

Michael Sahota is offering his Certified Agile Leadership class in the new year through BERTEIG – you can find dates at this site:

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

The post Top 10 Secrets of Agile Transformation with Michael Sahota appeared first on Agile Advice.

Categories: Blogs

Don’t Assume a 30% Allocation for Testing on Software Budgets

NetObjectives - Fri, 12/02/2016 - 12:24
The software engineering field has changed a lot over the years. There have been many advances in the field in terms of tools used, how teams build and test software, the speed of delivery, etc…   For teams that have not yet become a true agile team (every sprint is developed, tested and production ready), there is one pattern that continues to show itself, even though this pattern is a carry...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Cypress - Dealing with flaky tests

Xebia Blog - Fri, 12/02/2016 - 11:32
Test automation is all about feedback. Feedback that gives you quality updates about the features your team has built. A continuous green build is always the goal because this should give you the confidence you need to go to production. Unfortunately, I’m more used to a “traffic light build”, a build which passes and fails
Categories: Companies

Stuff Every Agile Development Team Needs to Know: A Primer

BigVisible Solutions :: An Agile Company - Thu, 12/01/2016 - 19:00

Sarah et al by puffy chairs 

So, you’re a development team member on a Scrum Team. We know that can sometimes be a little overwhelming. I’ve been in the business for more than a decade and yet the amount of change and dedication that top-notch software development requires is still daunting to me. With this in mind, my team and I have gone through our database of resources and pulled out what we think is the most relevant, useful information that you need to know to be effective in an Agile development team and to excel. There’s lots to learn if you are new, but a book a month and a link a week is a good pace. Call us if we can help. Good luck on your Agile journey!

Stuff Every Agile Development Team Needs to Know: A Primer


Start Here

Whether you’re looking at hardware, software or the people who make both work, if it’s Agile you’ll have hard time finding a better more comprehensive library of resources. We have lots of material, mostly in easy to consume pieces. Some of my favorites include:

Foundational Materials
  • Agile Manifesto – This is where it all begins – the basic tenets of Agile
  • Agile Principles – The expanded list of Agile principles
  • Scrum Guide – The Scrum Guide is the definitive “manual” for Scrum, continuously updated
  • Agile Glossary – Sometimes, the terminology associated with Agile can be confusing. Look here for a concise definition of just about every major term you’ll hear
  • – Introduction to XP values and rules
Understanding Roles Recommended Reading


Level UP Managing the work Avoiding Dysfunction Raising the technical game – great sites to visit often
  • – Great site from Uncle Bob, lots of videos on development, $6 to download
  • – Martin Fowler’s blog, as Thoughtworks employee
  • – Login to Facebook to see Kent Beck’s writings as a Facebook employee
  • – Examples exercises for learning and practice (30-60 min)
Let us practice! Getting management to let the team be agile Case Studies

The post Stuff Every Agile Development Team Needs to Know: A Primer appeared first on SolutionsIQ.

Categories: Companies

New Essential SAFe guidance article

Agile Product Owner - Thu, 12/01/2016 - 07:26

Earlier this year we spiked a concept called Essential SAFe, a set of minimal practices without which SAFe might no longer be ‘safe’. Essential SAFe serves as an assessment point, but it can also act as an easy entry point for organizations that aren’t ready for full-on SAFe, but want to start practicing and getting the benefits as soon as possible.

Over the last several months we’ve been busy gathering feedback on the idea, including hosting a dedicated workshop at the recent SAFe Summit. With strong encouragement from the community, Essential SAFe is now on track to find a more prominent and permanent position in a future release of the Framework, as well as integration into SAFe courseware and training where applicable.

Since its last iteration, the picture itself has matured and we have updated the definitions of some of the essential elements to highlight the critical nature of PI Planning, the System Demo, and the Inspect and Adapt event, to name a few.

Though it’s not yet fully supported in the SAFe ecosystem—and in the spirit of incremental development—we’re providing you with the latest set of resources, and are moving from this blog thread to a new Essential SAFe guidance article. Here’s what you’ll find there:

  1. A draft version of an Essential SAFe white paper
  2. A self-assessment of how an ART practices the essential elements of SAFe
  3. A downloadable version of the Essential SAFe picture in PowerPoint format
  4. A double-sided placement, with one side being the Essential SAFe picture and the other side the ten elements of Essential SAFe

This is still a work in progress, but with all the feedback we’ve received, we suspect this is close to the final version. We invite you to review these resources and provide any comments (right here) regarding Essential SAFe, the white paper, the self-assessment, the placemat, or any other resources you would like us to provide.

Thanks for your many comments so far,

Inbar and the Framework team

Categories: Blogs

Knowledge Sharing

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