Skip to content

Blogs

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

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

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. 

image

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:

image

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

IN THIS ISSUE

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.

JD

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:

Resistance-to-Change-Doesnt-Exist-tn

MHA15-Resistance-to-Change-Handouts-tn

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:

n=100
 
# We have 6 extra columns because we want to represent throwing of the dice which results in a final square > 100
M=matrix(0,n+1,n+1+6)
rownames(M)=0:n
colnames(M)=0:(n+6)
 
# set probabilities of landing on each square assuming that there aren't any snakes or ladders
for(i in 1:6){
  diag(M[,(i+1):(i+1+n)])=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
M=M[,1:(n+1)]
 
# 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
  v=M[,starting[i]+1]  
  ind=which(v>0)
 
  # Set no probability of falling on the starting squares
  M[ind,starting[i]+1]=0
 
  # Move all existing probabilities to the ending squares
  M[ind,ending[i]+1]=M[ind,ending[i]+1]+v[ind]
}

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
powermat=function(P,h){
  Ph=P
  if(h>1) {
    for(k in 2:h) {
      Ph=Ph%*%P
    }
  }
  return(Ph)
}
 
#new 
library(expm)
powermat = function(P,h) {
  return (P %^% h)
}

initial=c(1,rep(0,n))
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
distrib=initial%*%M
game=rep(NA,1000)
for(h in 1:length(game)){
game[h]=distrib[n+1]
distrib=distrib%*%M}
plot(1-game[1:200],type="l",lwd=2,col="red",
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…

Update

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:

distrib=initial%*%M
game=rep(NA,1000)
for(h in 1:length(game)){
game[h]=distrib[n+1]
distrib=distrib%*%M}
plot(1-game[1:200],type="l",lwd=2,col="red",
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

3128266497_077f9144af_z

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

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

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

ScrumSense.com - 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.

KANBAN FOUNDATION & ADVANCED COURSESKanban training

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!

LEADING SELF-ORGANISING TEAMS COURSE

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.

UPCOMING COURSES

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

Managing Flow

ScrumSense.com - Peter Hundermark - Thu, 04/09/2015 - 10:19

My next blog post is about “Managing Flow”. So many organisations I work with have benefited from using this technique to improve how they do what they do. I also felt it timely, since this is a key practice in Kanban, and Klaus Leopold will be coming to SA in May to provide two awesome two day courses on Kanban fundamentals, and scaling.

Traditional project management teaches us to manage resources and dependencies. Making sure everyone is busy is important because our plan is based on people optimisation and cost accounting. Managing flow in Kanban is the opposite of this and therefore often counter-intuitive.

Managing flow is a principle of Kanban and is about shifting the focus from the people to the work. So instead of managing people and keeping them busy all the time, we focus on managing the work and understanding how we get that work through the system faster.

The distinction is very important.

How do you manage flow? Visualise

Well the first step to managing flow is to understand where all the work in the system (by system I mean a human system designed to deliver value to the business) is. You need to visualise the value stream, and then visualise all the work in that value stream. Your value stream is the flow of work through your system, from concept to cash or beginning to end. This often depends on the level of granularity of your Kanban system. A good way to do this is to use a physical board, and to map your process from beginning to end. How does work flow into your system and how does it leave.

Limit WIP

Once you have the visualisation of where the work is, you need to begin to limit the amount of work in progress. Why would you want to do that I hear you ask?

There are many reasons to limit work in progress:

  • Create focus and prevent context switching: The more work there is in a system, the less focus any piece of work is getting. Context switching has a massive transaction cost and means that any single piece of work can end up taking longer than if there was focus around getting it done.
  • Decrease batch size:  Smaller batches mean faster feedback and shorter lead times.
  • Decrease complexity: The more work there is in a system the more complexity there is. Things that are deployed on the test environment affect each other. You need to manage all the dependencies that are created and the communication efforts of many more people. This all adds complexity and the higher the complexity the greater the risk.
  • Enable flow: The more work there is in a system, the more it will look like rush hour traffic and the less flow there will be. At 5:00pm in Sandton all the buildings in a four block area empty at the same time. The result of this is that the road infrastructure can’t handle the capacity and the roads become blocked and gridlocked. The same happens in software teams, and human systems when they have too much work in progress. By limiting the work in progress you can enable much better flow of work through the system.
Show blockages

Focusing on where the work is in a system, can help us have better conversations about which piece of work is the most important and where we need to spend our energy. It can also help us to see what is getting stuck. When something is stuck we want to visualise that. We want to understand first of all why it is stuck and second of all we want to make sure that our energy is focused on getting it unstuck. The tendency in systems designed for people optimisation is that the person whose current task is blocked by others will simply start on the next piece of work. The problem with this is that often the work item that is stuck is far more valuable than the next work item. Another impact of this behaviour, is that the ‘blocker’ gets moved into the background and forgotten about. It’s easy to forget things like that when there are another hundred other items right behind the one that’s stuck. This also means that when the work becomes unstuck it ends up in a queue, and each queue will have an impact on lead times.

Continuous Improvement

Having the visualisation, the limited WIP and the blockages visible, will give you large amounts of information about how your system works and what is in the way of getting things done. This is now a great starting point for conversations on how your system and processes can be improved and what can be done to better enable the flow of work. Talking about the work and managing the work through the system, means that we are focused on delivering value faster rather than on keeping people busy.

Keeping people busy can lead to longer queues, larger batches, more complexity and longer lead times. Managing flow will create focus on delivering value faster, and uncovering the challenges that get in the way.

If you want to know more about this have a look at http://www.klausleopold.com/.

 

The post Managing Flow appeared first on ScrumSense.

Categories: Blogs

Do you have an Agile Testing mindset ?

Agile World - Venkatesh Krishnamurthy - Wed, 04/08/2015 - 23:13

Here is my recent guest post for Zephyr…

image Performing Testing in Agile projects is not termed as Agile testing. Agile testing involves whole different mindset.  Then, how do you know your team has Agile testing mindset?  As a coach, I start this by asking testers the following few questions:

- Do have to wait until the development is done to start testing?

- Do testers feel there is a lack of time at the end of Sprint?

- Are testers blamed when defects are identified?

If testers answer “Yes” to some or all the questions above, then the team still has “Waterfall” mindset in guise of Agile. 

Another litmus test to try is to check the team’s wall which is popularly called “Kanban” wall. If you see a wall like the one below, where the “Test” ing is a separate column, then this is a smell.

Read the rest of the article on Zephyr

image

Categories: Blogs

Learning Opportunities for All

Johanna Rothman - Wed, 04/08/2015 - 20:10

If you are not on my Pragmatic Manager email list, you might not know about these opportunities to explore several topics with me this month:

An Estimation hangout with Marcus Blankenship this Friday, April 10, 2:30pm EDT. If you have questions, please email me or Marcus. See the Do You Have Questions About Estimation post. Think of this hangout as a clinic, where I can take your questions about estimation and help you address your concerns.

In the Kitchener-Waterloo area April 29&30, I’m doing two workshops that promise to be quite fun as well as educational:

  • Discovering the Leader Inside of You
  • An Agile and Lean Approach to Managing Your Project Portfolio

To see the descriptions, see the KWSQA site.

You do not have to be a manager to participate in either of these workshops. You do need to be inquisitive and willing to try new things. I believe there  is only room for two people for the leadership workshop. I think there is room for five people in the project portfolio workshop. Please do sign up now.

 

Categories: Blogs

Lebst du schon oder arbeitest du noch?

Scrum 4 You - Wed, 04/08/2015 - 08:12

Zum Thema Work-Life-Balance gibt es so viele Meinungen und Ideen, wie es Menschen gibt. Meistens gehen diese Meinungen davon aus, dass Arbeit und Leben zwei unterschiedliche Sphären sind. Viele Autoren vertreten die Ansicht, dass Arbeit generell so stressig ist, dass man sich davon erholen muss. Auf den ersten Blick haben sie recht: Die erfolgreichen Menschen Ende 20, Anfang 30 sind extrem belastet. Für den Erfolg im Beruf wird von ihnen viel erwartet: Überstunden sind an der Tagesordnung, Familie und Freunde müssen mit den hinteren Plätzen Vorlieb nehmen. In einem Artikel auf Elite Daily ist zu lesen, man solle sich daher den Arbeitgeber aussuchen, der zu den persönlichen Vorstellungen von Work-Life-Balance passt. Das ist eine schöne Idee, aber ich muss widersprechen.

Natürlich sollte man grundsätzlich darüber nachgedacht haben, ob man reisen will, welche Arbeitsbelastung man akzeptieren kann und wozu man bereit ist. Das tut man auch, wenn man erkennt, dass täglich genügend Zeit mit Pferd, Hund und Katze wichtiger ist als alles andere, oder dass die allabendliche Kneipentour mit Freunden einfach sein muss. Vielleicht reicht dazu ein Job, um finanziell über die Runden zu kommen – ohne jeglichen Anspruch auf Karriere oder täglich neue Herausforderung. Ich selbst habe Tennisplätze gebaut, Bonbons abgepackt und jahrelang als Krankenpfleger gejobbt (was man am niedrigsten Level als Hilfspfleger tatsächlich machen kann – die Profession der vollumfänglichen Krankenpflege zu erlernen dauert hingegen Jahre). Lauter Jobs, deren Aufgaben man mit ein wenig Einsatz leidlich erlernen kann. Meine Berufung waren diese Jobs aber sicher nicht. Was ein Beruf wirklich erfordert, können nur jene verstehen, die sich längere Zeit mit einem Beruf auseinandersetzen.

Fokus macht den Meister

Wer also nicht nur einen Job zum Geldverdienen suchen, sondern seine Berufung finden will, sollte sich bei allem Positiven an der Work-Life-Diskussion deutlich machen: Man kann nur in einer Sache richtig gut werden. Fokus ist das Gebot der Stunde. Um eine Sache oder einen Beruf intensiv zu erlernen und sich das Feld zu erarbeiten, braucht man einen starken Willen und Ausdauer. Gut zu werden braucht einigen Befunden zufolge etwa 10.000 Stunden oder zwischen 5 und 8 Jahren intensive Beschäftigung mit einer Profession. Wer schnell nachrechnen will: 10.000h/8 = 1.250 Tage; 1.250 Tage/5 Tage = 250 Arbeitswochen oder rund 5 Jahre. Über einen so langen Zeitraum den Fokus zu halten, erfordert sicher ein paar Opfer. Aber muss das zu Lasten der Familie oder des Körpers gehen? Müssen wir diese 10.000 Stunden so schnell wie möglich abarbeiten? Könnte es möglicherweise auch anders funktionieren? Ja – für den, der sich fokussiert. Für den, der sich einer Sache verschreibt, dranbleibt und für sich akzeptiert, dass lediglich Fortschritt, nicht Perfektion erreicht werden kann.

Pixabay

Pixabay

Fortschritt, nicht Perfektion

Die Young Professionals von heute ertragen das wesentlich schwerer als frühere Generationen. Soziale Netzwerke und die Medien gaukeln ständig vor, dass man zu langsam ist. Die 30-Jährigen von heute wollen eine Familie und erfüllte Beziehungen und Kinder und Freunde und gut aussehen und fit und sportlich sein. Nein – man muss sich nicht entscheiden, ob man das eine oder das andere will. Aber man muss sich fokussieren, einen Schwerpunkt setzen und das tun, was man wirklich tun will, denn: Wer etwas liebt, wird gut in dem, was er tut. Wer etwas gerne tut, wird freiwillig die eine oder andere Stunde mehr arbeiten. Weil es Spaß und Freude macht, erfüllend ist und nicht auslaugt. Wenn Michael Phelps seinen Sport nicht geliebt hätte, wäre er dann so weit gegangen, nicht nur fünf, sondern sieben Tage in der Woche zu trainieren? „From age 14 through the Beijing Olympics, Phelps trained seven days a week, 365 days a year. He figured that by training on Sundays he got a 52-training-day advantage on the competition. He spent up to six hours in the water each day. ‚Channeling his energy is one of his great strengths’, said Bowman. Not to oversimplify, but it’s not a stretch to say that Phelps channeled all of his energy into one discipline that developed into one habit—swimming daily.“ (Keller 2013, Pos. 586) Jeder von uns kennt dieses Gefühl, wenn man etwas gerne tut – man macht es länger und länger. Und natürlich gibt es auch jene Tage, an denen es keinen Spaß macht und man einfach nur durchhält. Wer etwas mit Erfüllung tut – und sei es der Beruf –, der hat auch Freunde, funktionierende Beziehungen und kann aktiv Sport treiben.

Beruf(ung) braucht Ausgleich

Was hat das nun alles mit der Wahl des richtigen Jobs (Verzeihung: Berufs) zu tun? Bei der Berufswahl geht es nicht darum, ob man die richtige Mischung aus Freizeit und Beruf gefunden hat. Es geht darum, einen Beruf zu finden, in dem man etwas tun kann, das man liebt und mit Begeisterung tun will. Wem das gelingt, der wird sich am Beginn vielleicht etwas verausgaben, weil es so viel Spaß macht. Aber schnell wird der- oder diejenige auch lernen, dass man sich auch noch um sich selbst kümmern muss. Dazu gehört es, einen Ausgleich zu suchen und Freunde zu finden, die diese Freude am Beruf auch aushalten. Wer sich fokussiert, wird im Beruf selbst wiederum lernen, bei einer Sache zu bleiben und sich nicht zu verzetteln. Dann bleibt Zeit für vieles andere. Ich selbst kann nur aus Erfahrung berichten, unsere Mannschaft macht es vor. Wir arbeiten viel und oft kommen das Sporttraining, der Freund oder die Familie etwas zu kurz. Aber wir machen unsere Arbeit , weil wir jeden Tag erleben dürfen, wie wirksam das ist, was wir tun. Wer sich wirksam (=mächtig im positiven Sinn) fühlt, der wird durch den Job gesund und nicht krank. Unsere Familien und Freunde erleben uns dann als erfüllt und zufrieden, nicht als gestresst. Arbeit und Leben sind keine Gegensätze, sondern ein Ganzes und das sollte es doch auch sein. Immerhin verbringen wir mit unserer Arbeit mindestens 8 Stunden täglich.

Literatur
Keller, Gary: The One Thing. The surprisingly simple truth behind extraordinary results. Kindle Edition. London: John Murray Press, Hodder & Stoughton, 2013.

Categories: Blogs

Features do not a Product Roadmap Make

Tyner Blain - Scott Sehlhorst - Tue, 04/07/2015 - 23:32

list of features

Last month, Mike Smart of Egress Solutions and I gave a webinar for Pragmatic Marketing on product roadmapping when working in agile environments. We had a great turnout of over 1500 people in the session – with not nearly enough time to answer all of the questions.

One attendee asked, “Please explain how a prioritized list of features is not a roadmap?

A fantastic question, which we did not see in time to answer during the call.

Why and What and When

The shortest answer I can come up with for the question – and probably all we would have had time to address during the call is the following:

A roadmap tells you both “why” and “what;” a list of features tells you only “what.” #prodmgmt

 

If all you need is the answer above, then this is a really short article for you – you can stop here.  There is some nuance to the above statement, which helps you address something more valuable – having a good roadmap.  If that’s interesting, then keep reading.

Which What?

Seven years ago this month, I joined in the fracas stirred up by an article where the author

  1. Described something (bad) which was not a roadmap
  2. Called it a roadmap, then
  3. Concluded that roadmaps are bad.

I would describe the author’s complaints [about roadmaps] as a list of things which can go wrong when you treat a list of features as if it were a roadmap.

Seven years later, this is still a source of confusion.  Perhaps it is the logical conclusion of anointing people with the title of “product manager” and not giving them the training, tools, and mentorship needed to learn the craft while simultaneously doing the work.

Some of the confusion may come from how we talk about roadmaps.  My tweetably short answer above leaves something to be desired.

Roadmap vs Backlog

All of the different containers for requirements document “what” the team will be building.  The different containers do this in different ways – and the roadmap has a qualifier.

  • PRD – identifies all the things which the team will build*, and the context in which those items are relevant or organized (e.g. the “Shopping Cart” section of the PRD for an ecommerce website will include the requirements for including controls that allow a user to update the quantity of items in the cart).
  • List of Features – possibly the most abhorrent of the containers – in the midst of a long list, will be the requirement to include an “update quantity” control with every item in the shopping cart.  If you’re lucky, the requirement will be tagged with “shopping cart” for ease of organizing / tracking progress.  Given the lack of context provided by a list of features, this requirement might be preceded by the “update inventory levels” requirement and followed by the “update user profile picture” requirement.
  • Backlog – when someone takes a list of features and sorts them by “give me this first” you get a backlog.  The story at the top of the list may be “As a [shopper in a hurry, who is multitasking while waiting in line at the DMV] I need to be able to update the quantity of items in my shopping cart because someone jostled me and I double-tapped my phone when I meant to single-tap, so that I only purchase the quantity I intended.” The question too many people are happy to dodge is why is this story at the top of the list? We’ll have to come back to that another time.
  • Roadmap – “Yes, but” is consultant speak for “I’m answering your question, but let me tell you the question you should have asked – and the answer to that question as well.” If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong.  Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher  persona.” Those descriptions of “what” are at a higher level, and articulate intentionality.  So, yes, a roadmap includes “what” – but not the same “what” as a backlog.

*As an aside – the team won’t actually build all of the stuff in the PRD, nor will they build what they build when the PRD says it will happen, and it will be over-budget.  But that’s another discussion entirely – and a big part of why “agile” came into existence in the first place.

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context.  This is the most important type of theme which would be part of a thematic roadmap.  Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

Context in Design

Requirements, by their nature, live in a particular context.  At one elevation or perspective, something is a requirement, defining and constraining what must be done; in a different context, that same something is a design choice representing a choice about how to do what must be done.

Several months ago, Andy Polaine posted a presentation about the future of UX, in which he presented a compelling imagery establishing the context in which design decisions are made.

Andy Polaine context slide

To fully appreciate the power of what Andy is talking about, I believe you have to view the above slide (#55), in the context of his presentation.  After experiencing it that way, the imagery has infused itself into how I frame product management activities.

If you cannot make time for now, the metaphor still works – solving the “visible and available” problem happens in the context of a wider environment (a larger, more complex problem), which is itself in the context of a wider environment, etc.

I find that I also apply the same concept when thinking about investments across differing time horizons.

On a given day, a member of the product team is implementing the code for adjusting the quantity of an item in the shopping cart.  Implementation is not the rote mechanical movements of a machine – it is a series of choices and actions.

Those implementation decisions happen within the context of implementing a story from the top of the backlog – helping someone place orders on their phone while waiting in line somewhere.  This context informs choices (like not requiring a modal dialogue to confirm the user’s choice when making a change in quantity, or making the change to “quantity of zero” be an explicit and distinct interaction).

The decision to prioritize empowering mobile users this quarter comes within the context of a decision to focus on 18 to 26 year olds as a key demographic for our product sales.  Improvements to the mobile shopping experience happen in conjunction with a change in inventory, a partnership with another company, and a targeted advertising campaign.

The focus on this particular group of customers is a “business design” choice as well.

Context in Agile A backlog lives within a roadmap, it does not replace it #agile #prodmgmt

 

A similar perspective on context is presented by Mike Cottmeyer of Leading Agile when looking at how you put the work the teams are doing into context. A “release backlog” or “product backlog” is defined within the context of strategy – which is manifested in the roadmap.

strategic agile context

Mike’s slide (#92 in a great deck) stops with “strategic” context for a release.  He and I have talked about this, and I believe we have strikingly similar views on context.  This view marries both the time-horizon and the problem-definition notions of context, from the perspective of the person doing the work and understanding the “why” of doing the work.

Within each context is framed a set of choices – providing both boundaries and flexibility to adapt to what we learn, but at a lower level of detail, with less ultimate potential value, for a shorter period of time.

Conclusion

A backlog – a prioritized list of features – is not a roadmap.  It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.” #agile #prodmgmt
Categories: Blogs

Neo4j: The learning to cycle dependency graph

Mark Needham - Tue, 04/07/2015 - 22:59

Over the past couple of weeks I’ve been reading about skill building and the break down of skills into more manageable chunks, and recently had a chance to break down the skills required to learn to cycle.

I initially sketched out the skill progression but quickly realised I had drawn a dependency graph and thought that putting it into Neo4j would simplify things.

I started out with the overall goal for cycling which was to ‘Be able to cycle through a public park':

MERGE (:Goal:Task {name: "Be able to cycle through a public park"})

This goal is easy for someone who’s already learnt to cycle but if we’re starting from scratch it’s a bit daunting so we need to break it down into a simpler skill that we can practice.

The mini algorithm that we’re going to employ for task breakdown is this:

  1. Can we do the given task now?
  2. Break the task down into something simpler and return to 1.

One of the things to keep in mind is that we won’t get the break down perfect the first time so we may need to change it. For a diagram drawn on a piece of paper this would be annoying but in Neo4j it’s just a simpler refactoring.

Going back to cycling. Since the goal isn’t yet achievable we need to break that down into something a bit easier. Let’s start with something really simple:

MERGE (task:Task {name: "Take a few steps forward while standing over the bike"})
WITH task
MATCH (goal:Goal:Task {name: "Be able to cycle through a public park"})
MERGE (goal)-[:DEPENDS_ON]->(task)

In the first line we create our new task and then we connect it to our goal which we created earlier.

Graph  9

After we’ve got the hang of walking with the bike we want to get comfortable with cycling forward a few rotations while sitting on the bike but to do that we need to be able to get the bike moving from a standing start. We might also have another step where we cycle forward while standing on the bike as that might be slightly easier.

Let’s update our graph:

// First let's get rid of the relationship between our initial task and the goal
MATCH (initialTask:Task {name: "Take a few steps forward while standing over the bike"})
MATCH (goal:Goal {name: "Be able to cycle through a public park"})
MATCH (goal)-[rel:DEPENDS_ON]->(initialTask)
DELETE rel
 
WITH initialTask, goal, ["Get bike moving from standing start", "Cycle forward while standing", "Cycle forward while sitting"] AS newTasks
 
// Create some nodes for our new tasks
UNWIND newTasks AS newTask
MERGE (t:Task {name: newTask})
WITH initialTask, goal, COLLECT(t) AS newTasks
WITH initialTask, goal, newTasks, newTasks[0] AS firstTask, newTasks[-1] AS lastTask
 
// Connect the last task to the goal
MERGE (goal)-[:DEPENDS_ON]->(lastTask)
 
// And the first task to our initial task
MERGE (firstTask)-[:DEPENDS_ON]->(initialTask)
 
// And all the tasks to each other
FOREACH(i in RANGE(0, length(newTasks) - 2) |
  FOREACH(t1 in [newTasks[i]] | FOREACH(t2 in [newTasks[i+1]] |
    MERGE (t2)-[:DEPENDS_ON]->(t1) 
)))
Graph  10

We don’t strictly need to learn how to cycle while standing up – we could just go straight from getting the bike moving to cycling forward while sitting. Let’s update the graph to reflect that:

MATCH (sitting:Task {name: "Cycle forward while sitting"})
MATCH (moving:Task {name: "Get bike moving from standing start"})
MERGE (sitting)-[:DEPENDS_ON]->(moving)

Graph  11

Once we’ve got the hang of those tasks let’s add in a few more to get us closer to our goal:

WITH [
  {skill: "Controlled stop using brakes/feet", dependsOn: "Cycle forward while sitting"},
  {skill: "Steer around stationary objects", dependsOn: "Controlled stop using brakes/feet"},
  {skill: "Steer around people", dependsOn: "Steer around stationary objects"},
  {skill: "Navigate a small circular circuit", dependsOn: "Steer around stationary objects"},
  {skill: "Navigate a loop of a section of the park", dependsOn: "Navigate a small circular circuit"},
  {skill: "Navigate a loop of a section of the park", dependsOn: "Steer around people"},
  {skill: "Be able to cycle through a public park", dependsOn: "Navigate a loop of a section of the park"}
 
] AS newTasks
 
FOREACH(newTask in newTasks |
  MERGE (t1:Task {name: newTask.skill})   
  MERGE (t2:Task {name: newTask.dependsOn})
  MERGE (t1)-[:DEPENDS_ON]->(t2)
)

Finally let’s get rid of the relationship from our goal to ‘Cycle forward while sitting’ since we’ve replaced that with some intermediate steps:

MATCH (task:Task {name: "Cycle forward while sitting"})
WITH task
MATCH (goal:Goal:Task {name: "Be able to cycle through a public park"})
MERGE (goal)-[rel:DEPENDS_ON]->(task)
DELETE rel

And here’s what the final dependency graph looks like:

Graph  13

Although I put this into Neo4j in order to visualise the dependencies we can now query the data as well. For example, let’s say I know how to cycle forward while sitting on the bike. What steps are there between me and being able to cycle around a park?

MATCH (t:Task {name: "Cycle forward while sitting"}),
      (g:Goal {name: "Be able to cycle through a public park"}),
      path = shortestpath((g)-[:DEPENDS_ON*]->(t))
RETURN path

Graph  14

Or if we want a list of the tasks we need to do next we could restructure the query slightly:

MATCH (t:Task {name: "Cycle forward while sitting"}),
      (g:Goal {name: "Be able to cycle through a public park"}),
      path = shortestpath((t)<-[:DEPENDS_ON*]->(g))
WITH [n in nodes(path) | n.name] AS tasks
UNWIND tasks AS task
RETURN task
 
==> +--------------------------------------------+
==> | task                                       |
==> +--------------------------------------------+
==> | "Cycle forward while sitting"              |
==> | "Controlled stop using brakes/feet"        |
==> | "Steer around stationary objects"          |
==> | "Steer around people"                      |
==> | "Navigate a loop of a section of the park" |
==> | "Be able to cycle through a public park"   |
==> +--------------------------------------------+
==> 6 rows

That’s all for now but I think this is an interesting way of tracking how you’d learn a skill. I’m trying a similar approach for some statistics topics I’m learning about but I’ve found the order of tasks isn’t so linear there – interestingly much more a graph than a tree.

Categories: Blogs