Skip to content

Feed aggregator

Using the two column case study

Thought Nursery - Jeffrey Fredrick - Sat, 04/11/2015 - 22:21

On March 25th the London Action Science Meetup held a session on Using the two column case study. In our previous session we introduced some of the fundamental ideas of Action Science, and then closed with an exercise based on the two-column case study. This time we started by creating our two-column cases, used them to identify our Skilled Incompetence, and tried to design more competent options.

Skilled Incompetence was Chris Argyris’s term for the effortless, automatic production of behaviors that led to outcomes other than what the actor desired. In the article of the same name he describes using the two-column case format to make the automatic behavior visible, so it could then be redesigned. Our group attempt was slightly different in that our goals were two fold:  first, we were helping each participant identify what alternatives they might have used, and second, we tried to identify what in those situations might act as a trigger for that automatic behavior. My theory is that identifying these contextual triggers will be helpful for “reprogramming” those automatic responses.

I won’t discuss the cases from our group discussion, but I can share three context that came up as troublesome:  disagreeing with a statement, having an uneasy feeling, and someone else trying to close off debate.

Our first context was a common one, so common that it seems innocuous: disagreement. Person A said X; person B disagrees with X. What could be simpler? The problem is that Person A and Person B might mean entirely different things by X! Consider the statement, “Yes, I’ve tested the changes in the new release.” What is meant by tested? Does that mean writing automated checks or performing manual testing? If automated, does it mean unit testing or acceptance checks or both? If manual testing, does it mean on a locally installed build, in the acceptance testing environment, or post-release in production? Or did this person do all those things and more? We could make assumptions — in fact we will almost certainly make assumptions! — but we can’t know we understand what was meant without asking. And so the first takeaway of the night was that if you disagree with someone you might first check to see if actually understand what they mean. Our re-designed statement: “You just made a statement that I think I disagree with, but I want to check I actually understand you and that we mean the same thing.” This is consistent with the mutual learning model in that we are open to learning that we are wrong and we are transparent in our reasons for asking for clarification.

The second context we discussed from our cases is having an uneasy feeling, but not having a concrete reason to justify your feeling that a proposed course of action is wrong. This can be an uncomfortable situation given that the values of the unilateral control model, our default way of behavior, include “act rationally” and “win, don’t lose”. From this unilateral control mindset sharing a feeling with nothing to back it up is a sign of weakness. But remember that our goal isn’t winning, it is mutual learning! From the mutual learning mindset sharing our feeling is consistent with sharing all relevant information. If nothing else, your conversational partner will learn how you are feeling, and can then make an informed choice how they want to proceed. Do they want to enquire into how you feel? Do they want to share some additional information they have which might reassure you? Do they want to share their own misgivings? As long as you are acting in good faith, not trying to use feelings as an insurmountable objection, we all agreed that sharing these feelings open the door to improved joint design.

The last context that came up from our cases was in some ways the most challenging:  how to respond when someone says “this is not open for discussion”? Once again we came back to the key distinction between Model I and Model II, which is the goal of controlling the outcome vs. the goal of learning. If I believe the decision that isn’t open for discussion is wrong, then from a Model I perspective I need to find a way to re-open the discussion, to have the decision reversed. But from a Model II perspective, I have the option to be curious, to seek to understand the decision rather than reopen the discussion. Going back to the Eight Behaviors I have the option of responding with something like, “I can accept that the decision is made, but I’d like to understand the reasoning. Can you share your reasoning and intent in making this decision?” With this strategy we can learn more about the interests of the person making the decision. Even better, if we are genuine in our curiosity, we just might learn something that would change our opinion!

Asking at the end of the meetup the group agreed this was a productive exercise. The two column case study format allowed us to identify areas where our communication wasn’t generating the outcomes we like. By discussing these situations with the group we were able to both come up with alternative behaviors and also to recognized the context that resulted in our original ineffective behavior. Our hope is that by continuing to practice in this way we will come to be more aware of our options and less skillfully incompetent.

To help with this process in our next meetup we will be introducing a new tool, The Ladder of Inference.

Categories: Blogs

Word Puzzles with Neo4J

Mistaeks I Hav Made - Nat Pryce - Sat, 04/11/2015 - 13:04
Stuck on a long train journey with only a single newspaper, my companion and I ran out of reading material and turned to the puzzle pages. One puzzle caught our attention: the “Word Morph”. Start with a four-letter word and turn it into another four letter word in a fixed number of steps, where at each step you can change only one letter in the word to create a new, valid word. For example, a puzzle may be to turn “HALT” into “SILO” in four steps. The solution is “HALT”, “SALT”, “SILT” and finally “SILO”. What interested me about this puzzle was that the domain can be be represented as a graph, with a node for every four-letter word and edges between every pair of words that differ by a single letter. Puzzles can then be solved by a path-finding algorithm. Word Morph puzzles represented as a graph So, I popped open my laptop and fired up Neo4J to experiment. I first needed a list of all four-letter words. Linux stores dictionary files in /usr/share/dict/ and I could easily extract all the four-letter words with grep: grep -E '^[[:alpha:]]{4}$' /usr/share/dict/british-english The data was a bit dirty: it contained a mix of upper and lower case and some letters had accents. I cleaned it up with the unaccent command, normalised it to lowercase with tr, and ensured there were no duplicates with sort -u: grep -E '^[[:alpha:]]{4}$' /usr/share/dict/british-english \ | unaccent utf-8 \ | tr [[:upper:]] [[:lower:]] \ | sort -u \ > puzzle-words I then imported the data into Neo4J as CSV data (the list of words is a valid single-column CSV file). The Cypher command to load it into the database is: load csv from "file:////puzzle-words" as cols create (:Word{word: cols[0]}) That gave me about 3000 nodes in my database, one for each word, but they were not yet linked by any relationships. I needed to link the words that are different by a single letter. The database is tiny, so brute-forcing the calculation for all pairs of words was practical in the time available, despite being O(n2) in the number of words. The trickiest bit was calculating the number of letter differences between two words. Unsurprisingly, Cypher doesn’t have a built-in function for this. Unlike SQL, Cypher does have some nice functional programming constructs that can be used to perform calculations: list comprehensions, EXTRACT (Cypher’s term for map), REDUCE (fold), COLLECT (used to turn rows of a result set into a collection) and UNWIND (used to turn a collection into rows in the result set). I used a list comprehension to create a list of indices where the letters of two words differ. The number of differences was then the length of this list. Given all pairs of words and the number of letter differences between the words in each pair, I created edges between the words (both ways) if there was a single letter difference: match (w1:Word), (w2:Word) where w2.word > w1.word with w1, w2, length([i in range(0,3) where substring(w1.word,i,1) <> substring(w2.word,i,1)]) as diffCount where diffCount = 1 create (w1)-[:STEP]->(w2) create (w2)-[:STEP]->(w1) That completed the data model. Now solving a puzzle was a simple Cypher query using the shortestPath function: match (start {word:'halt'}), (end {word:'silo'}), p = shortestPath((start)-[*..3]->(end)) unwind nodes(p) as w return w.word as step Giving: step ---- halt salt silt silo Returned 4 rows in 121 ms. Success! But my travelling companion was not happy. She didn’t want a computer program to solve the puzzle. She wanted to solve it herself. I’d ruined that. It looked like the rest of the train journey was going to pass amid a somewhat frosty atmosphere! But the same graph model that solves puzzles can be used to generate new puzzles: match (w) with collect(w) as words with words[toInt(rand()*length(words))] as start match p = start -[*3]-> (end) with collect(p) as puzzles with extract(n in nodes(puzzles[toInt(rand()*length(puzzles))]) | n.word) as puzzle unwind puzzle as step return step Again, a brute-force approach to selecting random words and puzzles that only works because of the tiny dataset1. And the query picks a random starting word without looking at its relationships with other words, so sometimes picks a word that cannot be morphed into another by three steps and returns an empty resultset. So, not perfect but good enough to pass the time until the end of the journey. For a more serious application of Neo4J, James Richardson and I gave a talk at ACCU2014 on how we used Neo4J to analyse the heap memory use of embedded Java code in Sky’s PVR system. Update: I found another implementation of this puzzle, which uses Java to build the graph and the Neo4J Java traversal API to solve puzzles. I’m struck how far Neo4J and Cypher have come since 2014, when that article was written. Cypher’s CSV import and functional programming constructs make it possible to solve the puzzle without any Java programming at all. Neo4J has become one of my go-to tools for quick-but-not-dirty data analysis. It would be great if a future version Neo4J added an operator for returning random rows of the result set↩
Categories: Blogs

Using the Lean Decision Filter: Should I finish what I’m working on or help the team ready new work items?

Guest Post by Yuval Yeret Once people start to get “Stop Starting Start Finishing” thinking (Kanban) or “focus on the current sprint” thinking (Scrum), a frequent question that comes up is how to deal with people who are required for different activities throughout the work life cycle. Example Scenarios The Kanban board shown above illustrates the […]

The post Using the Lean Decision Filter: Should I finish what I’m working on or help the team ready new work items? appeared first on Blog | LeanKit.

Categories: Companies

Stuck making a tough decision? Here’s how Three readers decided and delighted their customers.

Pivotal Tracker Blog - Fri, 04/10/2015 - 20:02

Some choices in life are easy. Coffee or tea? Tea, please.

But the choices you face as a software developer are a little harder. Jocelyn Goldfein, former Director of Engineering at Facebook, joined us on the second episode of Femgineer TV to talk about how to make smart tradeoffs in the name of happier customers and smoother product development.

If you haven’t seen the episode yet, you can watch it here!

Femgineer TV: How to Make Smart Tradeoffs When Building Software Products

At the end of the episode, we gave viewers a challenge: We asked them to write in and tell us about the last tough tradeoff they had to make when creating a product.

We’re happy to announce three winners from the challenge! 

Lawrence De’Ath ran the risk of losing his biggest and best customer when faced with a decision to change his plans for a locally installed product into an SaaS product.

Madhavi Arsoor had limited time: she could either spend it improving the UI of her blog or creating useful content for her readers.

Theron James debated whether to rewrite an iPhone app in familiar Objective-C, or do a retool and rewrite by having his team learn Swift first.

So, what did they choose? Here’s how it played out.

Lawrence’s tough call: Please an existing customer or serve more customers? 

Lawrence De’Ath’s team was debating whether to build their offering into a locally installed software product or go in a new direction and develop an SaaS product, which would be easily accessible to customers online. 

His challenge was that his top customer was keen on a locally installed product. 

But this would be more expensive to develop. What’s more, when he thought about the larger group of his potential customers, he realized that an SaaS product would serve them better. They’d save time because they wouldn’t have to install a local version, and it would be easy for them to try a product demo. 

“The risk was that the client would think we weren’t committed—or perhaps not able to develop an installed product. We chose to develop an SaaS product and begged our top customer to be patient. We presented it as a prototype we would all learn from,” Lawrence explains.

Once Lawrence chose to develop an SaaS product, he stepped back to see the results.

“The end result was that our top customer saw our progress in building the SaaS prototype, and other customers liked what they saw and wanted us to build out the SaaS prototype. We learned to hold our ground when the development process was right but didn’t fit exactly what the customer had in mind.” 

As you can see from Lawrence’s story, it’s easy for us to make tradeoffs based on the limitations of our technology, but as Jocelyn Goldfein explains in her interview with Femgineer TV (above), we get the best results when we also consider our customers’ needs.

Different technology stacks lend themselves to different solutions. But it’s not a technology-driven decision alone,” Goldfein says. “We need to think about what matters most to customers and what their expectations are for your product’s benefits.”

Madhavi’s time constraints: Improve her blog UI or create more content? 

Madhavi had limited time to dedicate to her blog, and she wanted to create new content but also had to figure out whether she should spend time improving its UI.

“My recent tradeoff was to allocate my time between building a great UI and creating useful and valuable content for my blog readers,” she explains. “The more we work on features the more we think of, and the to-do never ends. I had to decide between improving the appearance of my blog and adding additional content. The risk was losing more visitors due to the look and the feel of the site.” 

So, what did she do? 

“I returned to my my mission to deliver great content, and decided to spend some time on UI to make it appealing enough to convey the message I wish to convey. Without content, a great UI is of no value to my audience, but I wanted to make sure the UI was aligned with my message, so that I could focus more on creating content.” 

When she got feedback from her readers, they said that they placed more weight on the blog content than the UI. They liked her new look and easy navigation, but were more interested in the content than the blog’s look and feel—as long as the UI didn’t hinder their experience. 

“I’m now back to creating more content based on feedback from my readers, and when I have time, I’ll enhance the UI of the blog to improve the reader’s experience.” 

Theron’s choice: Rewriting and retooling an app at the same time? 

Technical debt is inevitable, and it can be hard to convince your team to take time out to do a rewrite. 

Theron James had to make not one, but two tough decisions! 

The first was the decision whether or not to do an app rewrite. He did a cost comparison in terms of the current technical debt’s impact on speed to market. It was taking his team three months to go from idea to market. Investing that time in doing a rewrite would make it so that they could build in two to three weeks instead of three months. Paying off the technical debt would speed up development time. 

Whenever there’s an opportunity to rework, there’s also a temptation to try something new . . .

Theron and his team were intrigued by the idea of using Swift. They debated whether to learn this new language for the app rewrite, or stick with the language they were familiar with: Objective-C. 

They knew that retooling and educating the team on Swift would take longer. Ultimately, they decided to stick with Objective-C.

“Although we were very excited about the prospect of Swift, given the tooling resources and team knowledge, we went with Objective-C. This has proven a good choice,” says Theron.

He continues, “Before we began the project, I shifted everyone from the management triangle of scope, cost, and schedule to an Agile Triangle of value, quality, and constraints (scope, cost, schedule) where we use the constraints to focus on two core values: quality and value (i.e., customer delight). 

“As we were doing the rewrite, we ran one week of sprints/iterations. We’d make mistakes but then take the time to learn from them and make corrections. Taking this approach meant that the cost was rarely ever more than a week’s worth of effort.

“We used behavior-driven development (BDD) to identify the largest areas of risk. This helped us prioritize the features with the greatest risk first.”

Decisions that delight customers 

Each of these viewers had a tough call to make and they took the time to evaluate their options. They considered the technology they were using, the business model they were operating under, and, importantly, their customer’s needs.

Goldfein agrees that delighting customers is key. “We have to be motivated by the person using our software. We have to remember that we cannot do everything in the world we’d like to do, so we should do what matters most to that person. When we design for the person, we do our best work.”

Want to participate in the next viewer’s challenge? The third episode of Femgineer TV airs in April. I’ve invited Ryan Hoover and Erik Torenberg, the founders of Product Hunt, to talk about: How to Build a Community of Evangelists for Your Software Product. Subscribe to our YouTube channel to know when it’s out!


The post Stuck making a tough decision? Here’s how Three readers decided and delighted their customers. appeared first on Pivotal Tracker.

Categories: Companies

Minimal Viable Product

I have a customer with a challenge. We've been working on an application and finished our first release. The business folks looked at it and came up with a list of "must-have's" they want before going live. The IT folks are pushing back, trying to keep additional work to a minimum before going to production. They even threw out the phrase "minimal viable product" or MVP as a way say what's the least that can be done.

However, MVP isn't about doing the least amount of work and calling it done. When taken in context of Lean Startup, it's part of a process. First you build the MVP and hypothesize what you think will happen when you go live, you measure against your hypothesis, and ideally learn something that takes you to the next step.

When I work with customers used to a more traditional approach to projects, I often see resistance to the MVP approach. They think they have one chance to get what they want, so they ask for everything. If they truly thought in terms of MVP, they would be able to think about it as what do they want first, knowing they get a chance to ask for more.

In some cases, the next step may not be in the same direction. In Lean Startup, there's the idea of the pivot, making a more fundamental change in direction. Groupon started as an online activism platform and PayPal started out building security software for handheld devices (think Palm Pilots, not smart phones). There are plenty of other examples out there of companies that didn't get the results they expected and made a pivot. Lean Startup is about getting to that point as fast as you can.

For my customer, we're going to time box another round of development, make them prioritize the must-haves, and then hopefully go to production, so they can see it they are moving in the right direction. Are you ready for your next step?
Categories: Blogs

Blink: Teams

Agile Management Blog - VersionOne - Fri, 04/10/2015 - 14:29









In his book, Blink, Malcolm Gladwell tells the story of marriage counselors who can tell whether a couple will stay married or get divorced after watching a very short video of the couple talking. The researchers have been able to spot subtle signs of contempt that would eventually lead to divorce.

When it comes to scaling enterprise agile, organizations have their own subtle signs of contempt, things I (and any other person, really) can observe that would lead to the conclusion that any attempt at agile will not have long-term success in that organization. With issues that cut so deep, trying to scale them will fail.

What is that sign? What do companies do that sabotages their attempts to improve?

The answer is simple: teams.

More specifically, it’s how organizations treat their teams.

If you have truly cross-functional teams that stay together, empowering them and allowing them to learn from each other and proceed through the stages of team development, then your chances of success will be very high. True teams, with trust, a sense of commitment to each other, and the ability to develop a sustainable pace of delivery, will lead your organization to bigger and better things.

Conversely, if you treat teams as mere boxes into and out of which people are shuffled, if teams are built up and torn down when the priority of projects change with the direction of the wind, and people are not allowed to stay together long enough to form bonds, you will never succeed.

I know, I know; that seems like a pretty dramatic statement, but it is true.

You will not succeed.

You may have some short bursts of “success” that come from heroic project work and a few rock stars, but that is not sustainable. Do not let this “success” fool you. You are not creating sustainable teams that will be able to constantly deliver valuable software.

It is not just keeping teams together; they must be truly cross-functional. Many companies are still holding onto the old vestiges of shared services models or “component and feature” team models. These will work, but will dramatically cut into your ability to scale.

Simply put, your ability to scale will be limited by the shared team with the lowest capacity. It does not matter what that shared team provides; I have seen it in many different flavors: security, EDI, data warehouse, and other internal specific applications. Whenever you lead yourself into believing these teams are “special” and need to be separate from the others, it will be difficult to scale.

Let’s look at a couple of examples.

First, we have a shared team that is supplying work to the feature teams. Notice how all of their velocities are similar (velocity scores are in the circles). The primary reason is that the shared team is holding them back. The teams are fighting for the scarce resource (the shared team) and waiting for deliverables from that team is artificially throttling their velocity. In other words, they could go faster, but cannot because of the bottleneck.

More troubling, if you have to focus all of the teams on one important goal, you would not be able to achieve your goal as fast, and their velocity would most likely drop due to their reliance on that shared team.







Now let’s look at a development group with truly cross-functional teams. First, you will notice that the overall velocities are higher, mainly because there is no shared team throttling their work. Second, if you had to focus all of the teams on one goal, all of the teams would be able to drive in that direction. No one team would become a bottleneck, and all are contributing to the goal.

So… how do we create cross-functional, sustainable teams?







First, know that it is not easy. It takes dedication, empowerment, and a top-down willingness to make it through the transition. We know from Dr. Bruce Tuckman, a researcher into the theory of group dynamics, that teams will struggle in the beginning. As they are going through “forming and storming,” productivity will crater. However, your patience will be rewarded once they normalize and then reach performing level.

Second, don’t be afraid to take risks with teams. Blend your “A” players with some junior people. Teams of all “A” players tend to linger in the storming phase as everyone is trying to be the alpha dog. Maybe let the teams choose themselves (just beware of the playground last-to-be-picked problem).

Finally, break up any cliques. Especially if you’re moving from a shared service model, those folks will most likely want to stay together. Why? They have been a team! But you need to spread their skills around (remember, we want CROSS functionality), so they need to find new teams.

The lynchpin to being able to consistently deliver great software is the empowered cross-functional team. They are the foundation of predictability within an organization. Without sustainable teams, executives tend to fall back into the “just get it done by X date” model. This model only serves to burn out the people and does not help the organization to achieve its goals. Building a solid foundation of teams takes time, effort, and patience, but the rewards greatly exceed the cost to get there.

Find out how VersionOne empowers successful teams with TeamRoom.

Categories: Companies

The Testing Manifesto

Growing Agile - Fri, 04/10/2015 - 11:37

About 2 years ago we created our version of a testing manifesto, as a quick summary of the mindset you should adopt when thinking about agile testing. We thought it was pretty cool :) Apparently so did many others, and the slide we had has been retweeted and added to many presentations since then. We recently redid the slide to be a bit nicer and more visually appealing:


This was a huge success and even got translated into french!

French Test Manifesto

Feel free to use the above images – please give us credit :)

Want to learn more?

We will be running a half day tutorial at EXPO:QA on Agile Testing Techniques for the Whole Team and would love to have you join us and to meet you. If you can’t make the tutorial we will be doing a quick talk on The Agile Testing Mindset on the Wed (10th June). We have a few discount codes for this conference – if you would like them just drop us an email: (First come first served!).

If you can’t attend our awesome tutorial – take a look at our book: Growing Agile: A Coach’s Guide to Agile Testing. This books includes a collection of workshops to help teams grasp these principles and adopt an agile testing mindset. It’s not just for testers. A key part of agile testing is that the whole team is involved, so we always run these workshops with everyone in the team – and you can too!

Categories: Companies

Overcoming the Obstacles to Achieving Agility and Delivering Business Value

Agile World - Venkatesh Krishnamurthy - Fri, 04/10/2015 - 09:38

I am  excited to say latest version of  Cutter IT Journal  has published my article “Overcoming the obstacles to achieving agility and delivering business value” .  I  authored this article exclusively for Cutter. 


In this article, I have articulated various issues that hinders agility in the organization. I am proposing the Systems thinking approach to solving the organizational and agile challenges.In order to achieve true agility, it is not sufficient to blindly follow the agile practices but to think beyond Agile. One should look at fixing the organization structure, focus on uplifting the relationship between business and IT and last but not least, fix the funding model.

I have shared some practical tips and solutions to achieve true agility beyond practicing Agile. The article is exclusively available for Cutter IT members and could be downloaded from here.

Here is the abstract of the article:


This months issue covers the following topics, including mine (highlighted)


Vince Ryan and David Putman open the issue by exploring several common difficulties experienced by groups moving to an Agile approach. These range from cargo cult behavior -- blind adherence to the what of Agile without knowing the why -- to the technical abilities of people to work in an Agile environment. The authors delve into key issues such as empowering people to actually make the changes required to support Agile, as well as ensuring that they have the proper skills to be able to thrive. The authors explore such areas as training, the recruitment of new people, and offshoring/outsourcing with respect to the changes that may be needed for an organization to truly reap the promised rewards of an Agile approach.

Our second article, by Cutter Senior Consultant Lynn Winterboer, examines one of the less traveled paths of Agile -- the implementation of Agile approaches in the DW/BI space. Winterboer addresses the challenges of breaking this type of work down into small slices, when it has traditionally been an "all or nothing" deal. She describes what is perceived as technical inefficiency in the small slice approach and how that is balanced by the business efficiency. Winterboer shows not only the advantages gained by earlier delivery of value, but also the effort required and "instability" incurred during the transition. In the end, both organizations in her case studies found ways to deliver smaller aspects of the total solution, providing more value sooner to their stakeholders.

In "Overcoming the Obstacles to Achieving Agility and Delivering Business Value" Venkatesh Krishnamurthy dispels the myth that "Agile is a tool" that can be discarded when you're "done,"much as a hammer is put away once a construction project is completed. He asserts, correctly in my opinion, that simply following Agile practices does not make an organization Agile. The use of systems thinking to view the transition in the context of the whole organization shows how the organizational structure, funding models, and business/IT relationship must change in order to support true business agility.

Finally, Alan Shalloway speaks of how Agile and Lean have "lost their shine" as the result of misapplication. My experience certainly supports this assertion. Shalloway proposes the use of a Lean-Agile hybrid approach that leverages both the organization-wide strengths of Lean and the team-level strengths of Agile. Like Krishnamurthy, he recommends the use of systems thinking in order to take a more holistic view of the context in which the Lean-Agile transition is taking place. Shalloway describes this ecosystem and the unexpected effects that can result when you don't consider groups outside of the development teams.

Read more about this issue here

Categories: Blogs

Boost Your Confidence with the Right Words

J.D. Meier's Blog - Fri, 04/10/2015 - 04:13

Confidence is one of those things that makes all the difference when it comes to realizing your potential.

So many people have great ideas and great ambitions, but lack the confidence to follow through when it counts.

They hold themselves back.

Their amazing and bold ideas turn into lackluster ideas, as fear starts talking (if they talk at all.)

A while back, a team in HR interviewed me on confidence, because enough people pointed back to me as somebody they saw as confident.

What HR wanted to know is, where does my confidence come from?

For me, it mostly came from a relentless focus on making impact.

I put my focus on doing great things, creating raving fan customers, and taking on big challenges.

Where you put your focus, instantly changes your confidence.

If you’re too worried about how you look or how you sound, then you aren’t putting enough focus on the amazing thing you are trying to do.

So it wasn’t confidence per se.  It was more like putting my focus on the right things.

But there was more to it.  I was confident because of a few basic beliefs:

  1. I believed I’ll figure it out
  2. I believed that if I screw up, I’ll learn faster
  3. I believed that I don’t need to be the answer, but that I can always find the answer

Another thing that helped is that one of our leaders was relentless about “exposing our thinking.”   He wanted us to always detach ourselves from our ideas.   He wanted us to present ideas without being attached to them so they could be criticized and evaluated in more objective ways.

This sounds simple, but you’d be surprised how difficult it can be to detach yourself from ideas.   But the beauty is that when you are able to do this, your focus changes from defending your ideas, to really helping to create better ideas.   And this little shift takes you from fear or lack of confidence, to purposeful exploration, with full confidence.

Anyway, I think we become the thoughts that we think, so I think it’s really important to fill our head with the right words on confidence.

To that end, here is roundup of some of the greatest confidence quotes of all time:

Confidence Quotes

See if you can find at least three that you can use to help add more juice to your day.

If there is one that I find myself referring to all the time, to remind myself to get up to bat, it’s this one:

“A ship is safe in harbor, but that’s not what ships are for.” – William Shedd

I learned it long ago, and it’s served me well, ever since.

While that one reminds me to do what I do best, it’s really this one that inspires me to expand what I’m capable of:

“Life shrinks or expands in proportion to one’s courage.” — Anaïs Nin

I hope you find the right words that give your confidence just the boost it needs, when you need it most.


Categories: Blogs

PMI-ACP LinkedIn Group Growing

Leading Answers - Mike Griffiths - Fri, 04/10/2015 - 03:04
Last week we passed 500 members for the new “PMI-ACP Exam Prep with Mike Griffiths” LinkedIn Group. That is a great start and plenty enough to begin discussing topics about the exam for people studying for the credential and those... Mike Griffiths
Categories: Blogs

Agile 2015 Conference Session

Leading Answers - Mike Griffiths - Fri, 04/10/2015 - 02:41
My presentation outline “Eat Risks for Breakfast, Poop Awesomeness All Day!” was accepted for the Agile 2015 Conference in Washington D.C., August 3-7. As much of the agile community seems engaged in scaling debates I am really happy to share... Mike Griffiths
Categories: Blogs

MHA 2015 Slides: Resistance to Change Doesn’t Exist

Agile For All - Bob Hartman - Fri, 04/10/2015 - 01:00

Thanks to everyone who attended my Mile High Agile 2015 session, “Resistance to Change Doesn’t Exist.” Here are the slides and handouts:



If you missed the session, you can catch it again at Humanizing Work 2015, our alumni conference, along with lots of other great advanced content.

The post MHA 2015 Slides: Resistance to Change Doesn’t Exist appeared first on Agile For All.

Categories: Blogs

R: Snakes and ladders markov chain

Mark Needham - Fri, 04/10/2015 - 00:02

A few days ago I read a really cool blog post explaining how Markov chains can be used to model the possible state transitions in a game of snakes and ladders, a use of Markov chains I hadn’t even thought of!

While the example is very helpful for understanding the concept, my understanding of the code is that it works off the assumption that any roll of the dice that puts you on a score > 100 is a winning roll.

In the version of the game that I know you have to land exactly on 100 to win. e.g if you’re on square 98 and roll a 6 you would go forward 2 spaces to 100 and then bounce back 4 spaces to 96.

I thought it’d be a good exercise to tweak the code to cater for this:

# We have 6 extra columns because we want to represent throwing of the dice which results in a final square > 100
# set probabilities of landing on each square assuming that there aren't any snakes or ladders
for(i in 1:6){
# account for 'bounce back' if a dice roll leads to a final score > 100
for(i in 96:100) {
  for(c in 102:107) {
    idx = 101 - (c - 101)  
    M[i, idx] = M[i, idx] + M[i, c]

We can inspect the last few rows to check that if the transition matrix is accurate:

> M[95:100,95:101]
   94        95        96        97        98        99       100
94  0 0.1666667 0.1666667 0.1666667 0.1666667 0.1666667 0.1666667
95  0 0.0000000 0.1666667 0.1666667 0.1666667 0.3333333 0.1666667
96  0 0.0000000 0.0000000 0.1666667 0.3333333 0.3333333 0.1666667
97  0 0.0000000 0.0000000 0.1666667 0.3333333 0.3333333 0.1666667
98  0 0.0000000 0.1666667 0.1666667 0.1666667 0.3333333 0.1666667
99  0 0.1666667 0.1666667 0.1666667 0.1666667 0.1666667 0.1666667

If we’re on the 99th square (the last row) we could roll a 1 and end up on 100, a 2 and end up on 99 (1 forward, 1 back), a 3 and end up on 98 (1 forward, 2 back), a 4 and end up on 97 (1 forward, 3 back), a 5 and end up on 96 (1 forward, 4 back) or a 6 and end up on 95 (1 forward, 5 back). i.e. we can land on 95, 96, 97, 98, 99 or 100 with 1/6 probability.

If we’re on the 96th square (the 3rd row) we could roll a 1 and end up on 97, a 2 and end up on 98, a 3 and end up on 99, a 4 and end up on 100, a 5 and end up on 99 (4 forward, 1 back) or a 6 and end up on 98 (4 forward, 2 back). i.e. we can land on 97 with 1/6 probability, 98 with 2/6 probability, 99 with 2/6 probability or 100 with 1/6 probability.

We could do a similar analysis for the other squares but it seems like the probabilities are being calculated correctly.

Next we can update the matrix with the snakes and ladders. That code stays the same:

# get rid of the extra columns, we don't need them anymore
# add in the snakes and ladders
starting = c(4,9,17,20,28,40,51,54,62,64,63,71,93,95,92)
ending   = c(14,31,7,38,84,59,67,34,19,60,81,91,73,75,78)
for(i in 1:length(starting)) {
  # Retrieve current probabilities of landing on the starting square
  # Set no probability of falling on the starting squares
  # Move all existing probabilities to the ending squares

We can also simplify the powermat function which is used to simulate what the board would look like after a certain number of dice rolls:

# original
  if(h>1) {
    for(k in 2:h) {
powermat = function(P,h) {
  return (P %^% h)

h = 1
> (initial%*%powermat(M,h))[1:15]
     0         1         2         3 4         5         6 7 8 9 10 11 12 13        14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
[1,] 0 0.1666667 0.1666667 0.1666667 0 0.1666667 0.1666667 0 0 0  0  0  0  0 0.1666667  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
     46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
[1,]  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0   0

One interesting thing I noticed is that it now seems to take way more turns on average to finish the game than when you didn’t need to score exactly 100 to win:

> sum(1 - game)
[1] 999
for(h in 1:length(game)){
ylab="Probability to be still playing")
2015 04 09 22 48 24

I expected it to take longer to finish the game but not this long! I think I’ve probably made a mistake but I’m not sure where…


Antonios found the mistake I’d made – when on the 100th square we should have a 1 as the probability of getting to the 100th square. i.e. we need to update M like so:

M[101,101] = 1

Now if we visualise he probability that we’re still playing we get a more accurate curve:

for(h in 1:length(game)){
ylab="Probability to be still playing")
2015 04 10 23 49 21

Categories: Blogs

Agile Quick Links #31

Notes from a Tool User - Mark Levison - Thu, 04/09/2015 - 17:16

Agile Quick Links

Some interesting reading for the Agile community:
Categories: Blogs

Understanding SAFe PI Planning with Cynefin

AvailAgility - Karl Scotland - Thu, 04/09/2015 - 16:05


Within SAFe, PI Planning (or Release Planning) is when all the people on an Agile Release Train (ART), including all team members and anyone else involved in delivering the Program Increment (PI), get together to collaborate on co-creating a plan. The goal is to create confidence around the ability to deliver business benefits and meet business objectives over the coming weeks and months – typically around 3 months or a quarter.

To many people this feels un-agile. Isn’t it creating a big plan up-front and defining work far ahead? However, a recent experience led me to realise why its not about the plan, but the planning and the dynamics of the event itself. In Cynefin terms, PI Planning is a catalyst for transition and movement between domains.

Let me explain.

Before PI Planning, and a move into an ART cadence, many organisations are in Disorder, relying on order and expertise when they should be using experiments and emergence. The scheduling of a PI Planning event triggers a realisation that there is  a lack of alignment, focus or vision. In order to prepare for the event people have to agree on what is important and what the immediate objectives, intentions and needs are. In short, what does the Program Backlog look like, and what Features should be at the top. The conversations and work required to figure are the beginning of a shallow (or sometimes not so shallow!) dive into Chaos.

During PI Planning is when the Chaos reaches a peak, typically at the end of Day One, as it becomes clearly apparent that the nice ordered approach that was anticipated isn’t achievable. More conversations happen, decisions are made about the minimum plausible solution and hypothesis are formulated about what might be possible. This is when action happens as everyone starts to pull together to figure out how they might collectively meet the business objectives and move the situation out of Chaos into Complexity.

After PI Planning there is still uncertainty, and the iteration cadences and synchronisation points guide the movement through that uncertainty. Feedback on the system development, transparency of program status and evolution of the solution are all necessary to understand progress, identify learning and inform ongoing changes. This may require subsequent dips into Chaos again at future PI Planning events, or over time the ART may become more stable as understanding grows, and PI Planning in the initial form may eventually become unnecessary.

It is this triggering of a journey that makes me believe that PI Planning, or equivalent “mid-range” and “big-room” planning events, are a keystone to achieving agility at scale for many organisations. I wonder how this matches other’s experience of successful PI Planning meetings? Let me know with a comment.

Categories: Blogs

Design the Right Product

Scrum Expert - Thu, 04/09/2015 - 16:02
We’ve all been there. You release a new feature, product or service, only to find it isn’t quite what your customers want or need. But by the time you release, it’s too late to make significant changes. Traditionally user experience design has involved a significant amount of upfront user research and design, to ensure we build products that meet customer needs. But this approach doesn’t always work so well within an Agile development environment. Lean UX draws inspiration from the philosophy behind Lean manufacturing, where the emphasis is on reducing waste ...
Categories: Communities

Lean Enterprise

TV Agile - Thu, 04/09/2015 - 15:52
Large organizations often struggle to leverage software to create innovative products. This is due to a number of organizational factors, including culture, governance and financial management, and the application of portfolio and program management strategies that do not take advantage of the unique characteristics of software. This talk discusses how to take a lean approach […]
Categories: Blogs

8 Reasons Why Agile Projects Fail

Agile Management Blog - VersionOne - Thu, 04/09/2015 - 15:14







It’s no secret agile projects can fail, but do you know the reasons for agile failure and how to avoid them? I could tell you why I think they fail. Instead, let me share what nearly 4,000 of your colleagues said were the eight reasons why agile projects fail and what you can do about it.

#1 Lack of Experience with Agile Methods

According to the 9th annual State of Agile™ survey, 44% of the respondents to the survey said they blamed the failure of agile projects on a lack of experience with agile methods.

Indeed, agile is first about how you think, but it also impacts what you do and how you do it. Teams that are deficient in the ability to apply basic agile practices tend to run into trouble. Investing in solid foundational training in agile techniques, and competent coaching as to their proper application, is money well spent.

#2 Company Philosophy or Culture at Odds with Core Agile Values

A total of 42% of the respondents said company philosophy or culture at odds with core agile values was the leading cause of failed agile projects. In fact, it was interesting to note that two of the top five reasons that caused agile failures revolve around the organization’s culture – company philosophy or culture at odds with core values and a lack of support for cultural transition (#5).

We know that agile is first about “how you think,” and then about “what you do.” If your organization’s culture is either ignorant of or outright hostile to agile principles and values, the prospect of success beyond isolated pockets of agile teams are slim. Understanding that agile impacts organizational values and facilitating that transformation is the first step to having a broader adoption of agile, and more success with agile as a means to successful delivery.

#3 Lack of Management Support

Some 38% of the respondents to the survey pointed to a lack of management support as the cause of failed agile projects.

This most typically pertains to “middle management.” In a poorly planned agile transformation, it’s not unusual for there to be great enthusiasm for agile at the team level and general support of agile at the executive level, leaving the project and program managers, functional “resource” managers, etc., in the middle of a messy “change sandwich.” Without strong executive guidance, this management layer can feel isolated and then simply dig in to survive. During an agile transformation, executive leaders need to model the behavior they want their management team to display, live the values they want them to adopt, and help them understand how they fit into the changing organization.

#4 External Pressure to Follow Traditional Waterfall Processes

Another 37% of respondents answered that they found external pressure to follow traditional waterfall processes impeding their projects’ success.

This is especially common in large enterprises, where there are agile teams and traditional waterfall teams working under the umbrella of the same portfolio. In such cases, the agile endeavors are usually being grafted into the existing traditional portfolio and project management (PPM) methodology, as opposed to the PPM methodology transforming to an agile approach. This doesn’t mean that agile can’t succeed, but it does mean that agile will need to coexist with (and to some extent, within) the traditional methodology. As I point out in the Get What you Want From Your Enterprise Agile Transformation white paper, two ways to facilitate that coexistence are to involve people from outside of the agile part of the organization in your planning, reviews, and retrospectives, and also to agree on mutual organizational interfaces for the exchange of information.

#5 Lack of Support for Cultural Transition

The survey found that 36% of the respondents saw a lack of support for cultural transition as the reason agile projects fail.

This is closely related to #2 and #3 above, Organizational values and norms evolve over time, and as they become established, they stubbornly resist change. Senior leadership holds the most leverage in facilitating the transformation of an organization’s culture to one that embraces agile. Tangible, active involvement at the executive level is critical to cultural transformation.

#6 A Broader Organizational or Communications Problem

According to the 9th annual State of Agile survey, 33% of the respondents said they found a broader organizational or communications problem causing agile projects to fail.

To reiterate what we’ve looked at in several of the preceding points, agile’s effectiveness beyond one-off teams here and there is dependent upon broader and deeper organizational buy-in to agile values and principles.

#7 Unwillingness of Team to Follow Agile

Unwillingness of the team to follow agile was the cause of failure for 33% of the respondents to the survey.

This tends to happen when the members of a team continue to identify themselves by function (Dev, QA, etc.). Team-level resistance can also happen when there is a team member with a “strong personality” who insists on retaining his/her position at the top of the pecking order. In both cases, it comes down to a perceived loss of identity or control. Executive leadership’s effective influence on the culture and the management team, thorough training, and capable team-level coaching are necessary to overcome these impediments.

#8 Insufficient training

Some 30% of the respondents to the survey said they blamed insufficient training for failed agile projects.

“Insufficient training” comes in three flavors:

1. Nobody received training;
2. Not everybody who needed training received it; or
3. Some/all received training, but the training wasn’t very good.

Skimping on training isn’t a good idea, and never leads to a successful agile organization. Make sure that everyone involved in your agile efforts receives rock-solid training. Do it early. “Everyone,” by the way, includes your executive leadership.


If you’re struggling with any of these barriers to agile success, this survey proves that you aren’t alone. The theme that underlies these impediments is that they can be traced back to cultural issues in the organization. In order to have significant and lasting agile success, there’s no getting around the need for strong executive leadership, solid training, and capable coaching.

Approximately 6% of respondents said “not applicable/don’t know.”

And 7.5% of the respondents told us that none of their agile projects could be considered “unsuccessful.” Which is great news.

So how are your agile projects doing? Are they succeeding or failing?

This is the second article in a series of blog posts on the 9th Annual State of Agile survey. You can read the first article on “Top 10 Tips for Measuring Agile Success” here.

Categories: Companies

Good Enough

Leading Agile - Mike Cottmeyer - Thu, 04/09/2015 - 15:10

Last week I was talking to the founder of a company regarding their ability to continue growing their existing products as well as creating an ability to innovate more quickly. One of the core challenges expressed in this conversation was the need to create fast feedback loops for new ideas. Driving innovation through the more predictable delivery capability was not providing the fast feedback needed and was creating disruption for the part of the organization charged with continuing to grow existing products.

It was clear that an innovation lab of some sort would remove those disruptions while allowing them to more quickly bring product ideas to market. The importance of gaining quick feedback on new product ideas was an important consideration. A challenge that kept coming up was that of building new capabilities that accomplish the goal of the requirements but are not really usable. In this particular industry, the capabilities provided must solve a problem but more importantly, do it in a way that is without friction and easy to understand in an instant.

coffe-cup-badAn analogy I used during this conversation was that we may have requirements to build a coffee cup that can hold 10 ounces and have a handle. The requirements are clear in what we need to deliver and we can do so. But, we can clearly create a coffee cup that meets the requirement but find that it is not usable…

It would be very helpful to introduce visual specifications in this instance. A quick visual that describes what the solution might look like would create alignment about what is being built and provide an ability to gain feedback on the usability of the solution. Had the visual above been used to discuss the specifications then we could quickly realize that though it does provide the ability to contain 10 ounces of liquid that can be carried easily, it doesn’t help with the need to drink from the cup.

coffee-cup-goodVisual specifications are a powerful way of increasing our understanding of requirements and increasingly help us determine if our intended solution will solve the problem and be usable. Visual specifications range from architectural diagrams, UI mock ups, and any visualization that can help us better understand requirements.

I will provide a bit of a warning, don’t go overboard with this. The visual specifications just have to be good enough. A picture of a whiteboard drawing is good enough. A screen capture with hand drawn changes are good enough. I’ve seen organizations spend more time creating visual specifications with high end tools than it would have taken just to build the working capability… Low fidelity visual specifications are what we’re after.

Visual specifications help create a richer language when communicating requirements. It improves collaboration and our ability to get feedback. If you’ve not tried this then I encourage you to do so and see if it keeps you from building unusable coffee cups.

The post Good Enough appeared first on LeadingAgile.

Categories: Blogs

News update 2015/04 – Kanban Foundation & Advanced Courses - Peter Hundermark - Thu, 04/09/2015 - 12:58

We hope you all had a lovely Easter break!

Joanne Perold talks about “Managing Flow” in our latest blog post. So many organisations she works with have benefited from using this technique to improve how they do what they do. The blog post is also timely, as this is a key practice in Kanban, and Dr. Klaus Leopold will be coming to SA in May to provide two awesome two day courses on Kanban fundamentals, and scaling……more.


Dr. Klaus Leopold, of LEANability in Vienna, will be running the popular Applying Kanban (Foundation) and Improving & Scaling Kanban (Advanced) certified courses on the 04-05 May 2015 and the 07-08 May 2015 respectively.

The Applying Kanban (Foundation) course provides a deeper understanding of Kanban for knowledge workers. The focus is on practical learning based on concrete problems of the participants. If you are keen to begin your Kanban journey or have already introduced Kanban and want to verify if the implementation complies with state-of-the-art Kanban knowledge then this is the course for you.

Awesome course, very interactive and informative. Absolutely coming back for the Advanced course. Thank you Klaus. – Doug Crawford, Entelect

Knowledge-busting, mind blowing, exciting, enjoyable, practical, sensible, plain down awesome…a great course to be on! – Yusuf Desai, Derivco

The Improving & Scaling Kanban (Advanced) course teaches advanced principles of the Kanban Method. It is for people who have already mastered the Kanban basics and wish to learn more.

Please follow this link to find out more and to take advantage of our 3-for-2 special offer!


We are pleased to announce the dates for the next Leading Self-Organising Teams course. This course will be taking place on the 07-08 July 2015 in Johannesburg. Louise Gardiner, of First Principles, and Peter Hundermark have joined forces to bring you this masterclass.

Learn state-of-the-art tools and practices for Lean/Agile organisations in an interactive classroom-based environment. Ensure that your teams are focusing on the rights things in the right way and at the right time. Get equipped now to face the complex leadership challenges of the 21st century. Book your place today!

Scrum Coaching Retreat Cape TownSCRUM COACHING RETREAT CPT

The first Scrum Coaching Retreat held in South Africa in February 2015 was a great success. Participants gained valuable learnings and enjoyed mingling with like-minded people. An outcomes website was created as a central repository for participants to capture their outputs. Feel free to take a look at what the teams got up to!

Agile CI2I is an output of one of the teams. The website serves as a collaborative space for agile coaches to share their experiences, tips and resources in working with organisational leaders. Follow this link to get involved.


Certified Scrum Master (CPT) – Fully booked!
13-14 Apr 2015
Steenberg Hotel, Cape Town

Applying Kanban (Foundation) – (JHB) – 3-for-2 Special!
04-05 May 2015
FNB Conference & Learning Centre, Sandton

Improving & Scaling Kanban (Advanced) – (JHB) – 3-for-2 Special!
07-08 May 2015
FNB Conference & Learning Centre, Sandton

Certified Scrum Master (JHB)
19-20 May 2015
FNB Conference & Learning Centre, Sandton

Course schedule and Book Online

The post News update 2015/04 – Kanban Foundation & Advanced Courses appeared first on ScrumSense.

Categories: Blogs

Knowledge Sharing

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