Skip to content

Blogs

LeanStartup : Customer Development Is Customer Coaching

Agile Thinks and Things - Oana Juncu - Sun, 10/19/2014 - 13:05
One of the most important activities as a Lean Startup entrepreneur is building the right interviews that will help building the "right product", as the Pretotyping Manifesto tells us.  My latest experience as  a Lean Startup mentor was with Business School class students.  With me in the mentoring team ( and in the photo) were Florian Champagne , Sébastien Orifici, who holds the innovation course, and Frank Debane , whom I thank to have invited me to join the team. The intense experience of helping about 10 projects structure the good questions for customers interviews,  revealed how similar  customer development and coaching are.  The highest value in Customer Development comes from asking good questions . The highest value of a coaching session does from asking "powerful questions". Do you see a pattern here? Entrepreneurs Are Asked To Be ... Customer Coaches Entrepreneurs learn from the Lean Startup approach that the first think they need to do is to challenge their vision. They are asked to stay humble and not impose their solution over customers that , hmmm, may not want that at all. They are asked to listen to market's voice and adapt their solution instead of trying to influence customers behavior.  The top 3 recommandations in true Customer development approach are :
  1. Don't rely of vanity metrics : number of likes , followers , visits on your product idea page is no sign of commitment 
  2. Be aware of false positives : don't count your family and friends in the measure of your success 
  3. Customers are experts of the problem  : if you want to build a successful solution, listen to real problem of customers instead of your ideas of the problem. 
So let's summarize what is the recommended entrepreneur's behaviour : 
  • Listen and observe, don't push your assumptions 
  • Customer is expert of the problem, they will find the most adapted solution 
Coaching experts will tell that  "listen and don't provide solutions" is the right attitude of a coach. Coaching is not about providing answers, coaching is about helping clients come out with answers that they are the only one to have , as the problem is theirs. So you see it ? Bright entrepreneur skilled in customer development are ... customer coaches.
Interview Questions are Powerful Questions The Lean "Gemba Walk" turned in "Get Out Of The Building" activity in Lean Startup ( as Lean Startup Machine initially defined it ) . Briefly it invites entrepreneurs to get into the "customer arena" and proceed to customer face-to-face interviews instead of running fancy marketing customer study analysis from company's ivory tower. To have effective feed-back , there is a key condition : prepare the customer interviews and ask the right questions right.  What are the patterns of good customer interviews questions ? Here is a quick hint :
  • Don't ask closed questions ( that will get a Yes/No answer). Closed questions are the main source of false positive and you won't get much of the binary choice.
  • Ask "Why", "How", "What" questions to avoid closed questions. Don't hesitate to repeat them . 
  • Invite to storytelling: ask customers to tell  their experience in the domain you're interviewing about 
  • Be interested about their problem ,  customers talk, you listen . 

For those people that are familiar with coaching the interviewing pattern should ring a bell. Because what is asked from entrepreneurs to build a solid delighted customer base is to have a customer and market ... coaching attitude .
Emerging Marketing Approach
Traditional Marketing may teach us that the key to success is to create a need. Today's world of frugality that has a tendency to run away from consuming behavior is probably not aligned anymore on this vision.Marketing of tomorrow that will bring make entrepreneurs successful might shift from "owning the market" to "coaching the market".And "create the need" will definitively shift to "make customer realise they have a need that they were not truly aware about". A completely different story.

Related Posts
Test Driven Business Featuring Your Lean Startup Products
Entrepreneurs , What Is Your Unfair Advantage 
Lean Startup For Services 



Categories: Blogs

Simplicity of Measure

Agile Tools - Sun, 10/19/2014 - 07:01

Fitbit_Dashboard

I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves.  Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.

It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.


Filed under: Agile, Tools Tagged: fitbit, measure, Metrics, Tools
Categories: Blogs

Neo4j: LOAD CSV – The sneaky null character

Mark Needham - Sat, 10/18/2014 - 12:49

I spent some time earlier in the week trying to import a CSV file extracted from Hadoop into Neo4j using Cypher’s LOAD CSV command and initially struggled due to some rogue characters.

The CSV file looked like this:

$ cat foo.csv
foo,bar,baz
1,2,3

I wrote the following LOAD CSV query to extract some of the fields and compare others:

load csv with headers from "file:/Users/markneedham/Downloads/foo.csv" AS line
RETURN line.foo, line.bar, line.bar = "2"
==> +--------------------------------------+
==> | line.foo | line.bar | line.bar = "2" |
==> +--------------------------------------+
==> | <null>   | "2"     | false          |
==> +--------------------------------------+
==> 1 row

I had expect to see a “1” in the first column and a ‘true’ in the third column, neither of which happened.

I initially didn’t have a text editor with hexcode mode available so I tried checking the length of the entry in the ‘bar’ field:

load csv with headers from "file:/Users/markneedham/Downloads/foo.csv" AS line
RETURN line.foo, line.bar, line.bar = "2", length(line.bar)
==> +---------------------------------------------------------+
==> | line.foo | line.bar | line.bar = "2" | length(line.bar) |
==> +---------------------------------------------------------+
==> | <null>   | "2"     | false          | 2                |
==> +---------------------------------------------------------+
==> 1 row

The length of that value is 2 when we’d expect it to be 1 given it’s a single character.

I tried trimming the field to see if that made any difference…

load csv with headers from "file:/Users/markneedham/Downloads/foo.csv" AS line
RETURN line.foo, trim(line.bar), trim(line.bar) = "2", length(line.bar)
==> +---------------------------------------------------------------------+
==> | line.foo | trim(line.bar) | trim(line.bar) = "2" | length(line.bar) |
==> +---------------------------------------------------------------------+
==> | <null>   | "2"            | true                 | 2                |
==> +---------------------------------------------------------------------+
==> 1 row

…and it did! I thought there was probably a trailing whitespace character after the “2” which trim had removed and that ‘foo’ column in the header row had the same issue.

I was able to see that this was the case by extracting the JSON dump of the query via the Neo4j browser:

{  
   "table":{  
      "_response":{  
         "columns":[  
            "line"
         ],
         "data":[  
            {  
               "row":[  
                  {  
                     "foo\u0000":"1\u0000",
                     "bar":"2\u0000",
                     "baz":"3"
                  }
               ],
               "graph":{  
                  "nodes":[  
 
                  ],
                  "relationships":[  
 
                  ]
               }
            }
         ],
      ...
}

It turns out there were null characters scattered around the file so I needed to pre process the file to get rid of them:

$ tr < foo.csv -d '\000' > bar.csv

Now if we process bar.csv it’s a much smoother process:

load csv with headers from "file:/Users/markneedham/Downloads/bar.csv" AS line
RETURN line.foo, line.bar, line.bar = "2", length(line.bar)
==> +---------------------------------------------------------+
==> | line.foo | line.bar | line.bar = "2" | length(line.bar) |
==> +---------------------------------------------------------+
==> | "1"      | "2"      | true           | 1                |
==> +---------------------------------------------------------+
==> 1 row

Note to self: don’t expect data to be clean, inspect it first!

Categories: Blogs

Make Resolving Impediments a Habit

Agile Tools - Sat, 10/18/2014 - 08:43

David_City_Rey_grocery_store

I’ve talked a lot about the rigors of finding and resolving impediments for a team. There is one thing that I have left out: the people part. I learned this lesson at a conference that I was co-hosting. I had been in charge of setting up the food for the event. Getting the caterer, arranging for meals, that sort of thing. As you might imagine, it’s a pretty tough job to satisfy the dietary requirements for a very large group of people. I learned of whole categories of food allergies and needs that I had never even imagined existed! There was a little bit of every imaginable combination. Everything from your standard gluten free diet all the way to lacto-ovo-pesca-leguma-veganitarians (OK, I made that last one up).

We did the best we could to satisfy the needs of most folks and pretty much called it good. About halfway through the conference, someone mentioned that there was no food that fit in their dietary needs. I expressed my sympathies and referred them to the grocery store around the corner. I really didn’t give it another thought. A few minutes later, I heard the same complaint made by the same person, but this time the reply was, “I’ll get you something, I’ll be right back” And that person ran off to the store themselves. Wow!

I was humbled. The difference between my reaction and theirs was the difference between someone who could empathize and take action to resolve the impediment, and someone who couldn’t. The lesson I learned that day was that in order to help people with their impediments, it takes empathy. You have to feel their need, and be receptive to doing anything to help them out. I think I had missed that before. That willingness to serve the needs of others is really important. All the strategies in the world for resolving impediments won’t help anyone if you don’t care.


Filed under: Agile, impediment Tagged: Impediments, leadership
Categories: Blogs

R: Linear models with the lm function, NA values and Collinearity

Mark Needham - Sat, 10/18/2014 - 08:35

In my continued playing around with R I’ve sometimes noticed ‘NA’ values in the linear regression models I created but hadn’t really thought about what that meant.

On the advice of Peter Huber I recently started working my way through Coursera’s Regression Models which has a whole slide explaining its meaning:

2014 10 17 06 21 07

So in this case ‘z’ doesn’t help us in predicting Fertility since it doesn’t give us any more information that we can’t already get from ‘Agriculture’ and ‘Education’.

Although in this case we know why ‘z’ doesn’t have a coefficient sometimes it may not be clear which other variable the NA one is highly correlated with.

Multicollinearity (also collinearity) is a statistical phenomenon in which two or more predictor variables in a multiple regression model are highly correlated, meaning that one can be linearly predicted from the others with a non-trivial degree of accuracy.

In that situation we can make use of the alias function to explain the collinearity as suggested in this StackOverflow post:

library(datasets); data(swiss); require(stats); require(graphics)
z <- swiss$Agriculture + swiss$Education
fit = lm(Fertility ~ . + z, data = swiss)
> alias(fit)
Model :
Fertility ~ Agriculture + Examination + Education + Catholic + 
    Infant.Mortality + z
 
Complete :
  (Intercept) Agriculture Examination Education Catholic Infant.Mortality
z 0           1           0           1         0        0

In this case we can see that ‘z’ is highly correlated with both Agriculture and Education which makes sense given its the sum of those two variables.

When we notice that there’s an NA coefficient in our model we can choose to exclude that variable and the model will still have the same coefficients as before:

> require(dplyr)
> summary(lm(Fertility ~ . + z, data = swiss))$coefficients
                   Estimate  Std. Error   t value     Pr(>|t|)
(Intercept)      66.9151817 10.70603759  6.250229 1.906051e-07
Agriculture      -0.1721140  0.07030392 -2.448142 1.872715e-02
Examination      -0.2580082  0.25387820 -1.016268 3.154617e-01
Education        -0.8709401  0.18302860 -4.758492 2.430605e-05
Catholic          0.1041153  0.03525785  2.952969 5.190079e-03
Infant.Mortality  1.0770481  0.38171965  2.821568 7.335715e-03
> summary(lm(Fertility ~ ., data = swiss))$coefficients
                   Estimate  Std. Error   t value     Pr(>|t|)
(Intercept)      66.9151817 10.70603759  6.250229 1.906051e-07
Agriculture      -0.1721140  0.07030392 -2.448142 1.872715e-02
Examination      -0.2580082  0.25387820 -1.016268 3.154617e-01
Education        -0.8709401  0.18302860 -4.758492 2.430605e-05
Catholic          0.1041153  0.03525785  2.952969 5.190079e-03
Infant.Mortality  1.0770481  0.38171965  2.821568 7.335715e-03

If we call alias now we won’t see any output:

> alias(lm(Fertility ~ ., data = swiss))
Model :
Fertility ~ Agriculture + Examination + Education + Catholic + 
    Infant.Mortality
Categories: Blogs

What projects are suitable for Agile?

At Agile Tour Sydney 2013, I participated in an Open Space session triggered by:
What projects are suitable for Agile?This is my response.

To start, we should determine how we would assess our answer.  This leads to two more questions:
  1. What does it mean for an approach to be "suitable" for a project?
  2. What do you mean when you say "Agile"?
What does it mean for an approach to be "suitable" for a project?I'll say that an approach is suitable for a project if, compared to alternate approaches, it provides a higher likelihood of project success.
Which leads to...
What defines project success?The typical response might be "on time, on budget, on scope".  I'll say that this response is incorrect.
People don't fund projects in order to get something "on time, on budget, on scope"; they fund projects to get desired overall outcomes.  If I can get a better desired overall outcome that happens to not be on time, on budget, on scope, why would I consider that a failure?
But what about impact on other projects if this project is late, uses up too much available capital, doesn't complete dependent capabilities, etc.?  This is a good question and leads to...
Project outcomes can only considered successful in the context of overall organisational outcomes.
So if overall organisational outcomes are improved, it still doesn't matter if a project is "on time, on budget, on scope" per se.
This way of defining success is a typical difference in fundamental assumptions for non-Agile vs Agile approaches.  And this brings us to the second question...What do you mean you say "Agile"?I've blogged about what people mean when that say "Agile" before.
The short version is that when I say "Agile", I'm referring to Agile as a doctrine or culture, that is a set of fundamental principles and assumptions that guide behaviour.  This doctrine / culture is associated with a particular set of practices, but those practices are secondary.
The principles I consider primary are:
  1. Reduce the distance between problems and problem-solvers
  2. Validate every step
  3. Take smaller steps
  4. Improve as you go
So the question becomes, for what kind of projects are these principles unsuitable?
When someone asks the question "What projects are suitable for Agile?", I think they are inadvertently asking the question "What projects are more difficult to apply Agile principles?".  I can imagine that a particular type of project, with a particular level of team and organisational maturity, would find it so difficult to apply some or all Agile principles that the end result is unsuitability, that is, a lower likelihood of providing desired overall outcomes.
To sum up...My answer to the question: What projects are suitable for Agile?Projects where your team and organisation have the skill, maturity, and support, to apply Agile principles to successfully deliver desired overall outcomes.
Categories: Blogs

Partnerships & Possibilities, Episode 2, Season 6

Partnership & Possibilities - Diana Larsen - Fri, 10/17/2014 - 15:00

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 2: REVISITING INFLUENCE

Photo Credit: Send me adrift. via Compfight cc

How do  you observe yourself or your colleagues influencing each other? What kinds of influence do you see as critical for lasting positive changes?

Leave a comment on this blog or email us at info@futureworksconsulting.com

Summary

[1:40] Sharon is working with the leadership of a large non-profit with an enormous number of volunteers, who do the real work of the organization.

[4:00] Working with volunteers is all about building a sense of community and purpose to motivate people to do what needs to be done – all through “influence”.

[6:15] Power and influence are orthogonal.

[8:05] Compliance and influence are also different things.

[10:20] Motivation comes from within – it doesn’t get applied from outside. You can’t inoculate people with it.

[15:55] The model Sharon’s looking at currently looks at 6 types of influence.

[20:20] Convincing, selling, and so on, is also not influence. And influence will get you more mileage.

[22:23] Benefit must accrue on both sides for change to last – this is real influence.

[24:30] You can give feedback if you can do it with caring and respect. If you don’t care and respect the other person, don’t bother. The same is true of influencing – do I care about this person?

[28:00] An important element of influence is creating an environment that supports what you want to have happen.

 

Categories: Blogs

The Agile Reader – Weekend Edition: 10/17/2014

Scrumology.com - Kane Mar - Fri, 10/17/2014 - 08:53

You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.

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

  • #IT #Job in #Strongsville, OH: Web Business Analyst – Agile Scrum Master 14-267 at Medical Mutual #Jobs
  • Check out this SCRUM MASTER Overview on YOUTUBE: #scrum #agile
  • RT @FreeScrumEbook: Check out this SCRUM MASTER Overview on YOUTUBE: #scrum #agile
  • How to Plan an Agile Sprint Meeting? – http://t.co/qfwlkKpZi6
  • Agile by McKnight, Scrum by Day is out! Stories via @AgileUniversity @BCSMemberGroups @KristinRunyan
  • Skyhook Wireless is looking for: Agile Project Manager (Scrum Master)
    #job
  • Why Are Scrum Teams Supposed to Be Small? #agile #scrum #development #framework
  • Pic from last nights event: GA Presents at Sydney Agile + Scrum Meetup. See more events at GA: http://t.co/AsofQyj2wd
  • I’m hiring – Scrum Master in Rock Island, IL #Scrummaster #agile
  • PessoALL, está aberto as inscrições para treinamento “Scrum Foundations” dia 22/11 #scrum #agile #adaptworks
  • Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • RT @yochum: Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • RT @yochum: Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • RT @yochum: Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • #jobs4u #jobs Seeking Boston Based Agile Project Leadership / Scrum Master / Product Owner … #projectmanagement
  • #HongKong #Jobs Application Developer, Java, Oracle, Unix, Linux, SQL, Agile, Scrum, Test Driven… #Job #HongKongJobs
  • RT @jobz4pm: #jobs4u #jobs Seeking Boston Based Agile Project Leadership / Scrum Master / Product Owner … #project…
  • Komt er een vierde vraag tijdens de daily standup? Kijk vanavond op #scrum #agile
  • Skyhook Wireless is looking for: Agile Project Manager (Scrum Master)
    #job
  • #Scrum Master With Agile Experience #ScrumJob #TCS #Chennai #Job @sathish_ganesh @vinothselvam F
  • Avoidance of Organizational Dysfunction Leads to Scrum Masters’ Failure – #Agile #Scrum
  • Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • RT @CodehireJobFeed: Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • RT @CodehireJobFeed: Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • Scrum Methodology, Mountain Goat Software | Scrum, as mentioned w.r.t JetBrains’ issue tracker framework
  • RT @yochum: New Article: Estimate Before, During, and After the Software Project #agile #scrum
  • 32 Scrum master interview questions – #scrum #coaching #agile
  • Do you know what are the characteristics of a great Scrum Master? Check if you have them: #scrum #agile #coaching
  • Video course: Scrum: An Introductory Course To #Agile | Was $99 Now just $24! | by @BrainConcert
  • RT @CodehireJobFeed: Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Chennai, apply now! #job http://t.co/a4yzUUUK06
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Chennai, apply now! #job http://t.co/F7dE8ijORZ
  • RT @lgoncalves1979: 32 Scrum master interview questions – #scrum #coaching #agile
  • RT @ITJobsInChennai: #Scrum Master With Agile Experience #ScrumJob #TCS #Chennai #Job @sathish_ganesh @vinothselvam…
  • Scrum’s creators seek definitive place for Scrum knowledge #agile #scrum #ITlife #devlife
  • RT @Scrumartikelen: Leuk en duidelijk filmpje waarin het #agile #Manifest eenvoudig wordt toegelicht: #scrum
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture in #Chennai http://t.co/YwiYFna94j
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Chennai at #Accenture. Apply now! #job http://t.co/s7o7mVW8JC
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Chennai at #Accenture. Apply now! #job http://t.co/UWN1lqK0zg
  • ☆★☆ JOB ALERT ☆★☆ #Job #Malvern – Project Manager/Scrum Master (AGILE exp REQUIRED) view full details
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Chennai) #job http://t.co/kcMzdpIQTs
  • Agile Development and Scrum (@ Mood Cafe in Istanbul, Turkey) http://t.co/0YYjKee0mx
  • Bij zoeken we een Software Engineer BI – #Oracle #SQL #SCRUM #Agile
  • Categories: Blogs

    Keeping It In the Family

    Agile Tools - Fri, 10/17/2014 - 06:47

    art-child-family-2194-366x550

    I was asked the other day, “Do you use Scrum at home?” It’s not the first time that I’ve been asked this question. The honest answer is: no. Oh, I’ve used bits and pieces here and there. I’ve put together a taskboard to track work on the occasional big household project. I’ve even built a backlog from time to time. But that is about the extent of it. I’ve been married for nearly twenty years – I’m not about to screw it up with Scrum or any other method for that matter.

    You won’t find me standing around with the kids doing a daily standup. There is no weekly planning meeting on my family calendar. And the only retrospective that I do is after getting caught leaving the toilet seat up (“Doh!”). Nope, I’ve got to be honest, my household isn’t very agile.

    You might ask, “Why not?”

    Dang, that’s a really good question. I’m not sure that I have a good answer. Maybe I just want to leave all that stuff at work. But if that were the case, then why do I go home and write this blog? No, that’s not it. Maybe there really has been no structure modelled in my family life before. In fact, the very idea of doing that kind of “work” at home makes me cringe a little bit. I guess I feel like we have things under control. Maybe I don’t even want that control. It’s really hard to say.

    I think there is value in sharing the practical time management techniques that I use at work with my kids. I didn’t hesitate to introduce them to pomodoros when my daughter was struggling to stay focused on her homework. It felt really good to be able to introduce her to a tool that would help her be successful. She loves pomodoros! The kids like all the fooling around that I do with self-experiments around the house (“Hey! Look at Daddy!”). They always want to know what kind of nutty thing Dad is doing this week.

    However, I’ve never felt a compelling need to have any kind of formal family meeting at all. Call me a bit waterfall. I guess when it comes to my family I only want to give them the techniques that they need for the problems they have. I don’t want to burden them with a framework. Got a problem with focus? Use pomodoros. Does the problem seem too large? Break it down into stories. No progress? Try iterating.

    When I can provide a helpful technique that solves their problems (agile or not), I feel like Superman. Seriously folks, there is no better feeling in the world. There is no preaching. I don’t lecture them on the perils of waterfall. To my kids a waterfall is something you ride a log down at Disneyland. I aim to keep it that way as long as possible.

    I guess, in retrospect it’s not such a bad approach for introducing agile practices for anyone, regardless of whether they are in your family or not. In fact, why would you treat a team any differently than your family? Aren’t they just that – your extended family? Can we use this to inform how we approach introducing Agile Practices to our teams?

    Maybe we just introduce them to the tools they need to solve the problem that they have in the moment. Perhaps that’s how we start. That’s how we demonstrate value and earn trust. Not by dumping some framework they must comply with on their heads.

    Hmmm….I think I’ve been doing it wrong.

    Introduce agile practices to your team like you would to your family. Give them only what they need and let them figure out the rest.


    Filed under: Agile, Coaching, Teams Tagged: Agile, family, practices, Scrum
    Categories: Blogs

    The Economics of Compassion in the New Economy

    Leading Answers - Mike Griffiths - Fri, 10/17/2014 - 03:24
    This article is less about agile techniques and more about the people related challenges of today’s agile projects. As work switches from industrial work to knowledge work, companies face a perfect storm of employee engagement and retention issues. On the... Mike Griffiths
    Categories: Blogs

    NeuroAgile Quick Links #5

    Notes from a Tool User - Mark Levison - Thu, 10/16/2014 - 23:46

    Knowing your Myers-Briggs type is almost as common as knowing your credit score – maybe even more so. It’s widely considered to be the most frequently used personality test, but evidence – or, rather, lack thereof – suggests that it’s totally meaningless and organizations should stop using it.

    CEOs get paid too much, according to pretty much everyone in the world. But how much do you think they actually get paid, versus should get paid? Recent research says that, globally, we’re very naive about the actual disparity between what we think is fair and what they collect.

    How much time do you spend in front of an electronic screen every day? Your computer at work, tablet to read on the bus, TV in the evening, phone to just quickly check email or peek in on Facebook… It all adds up, to about 6 or 7 hours a day if you’re average. It’s tough to be bored with so many things to occupy our every free moment. But being bored is important to being creative and productive.

    Children are taught about nutrition and exercise for their bodies, but what about keeping their brain fit and healthy? Barbara Arrowsmith Young, author of “The Woman Who Changed Her Brain,” makes the point that every kid should practice stress reduction and targeted cognitive exercises at school, and it applies just as much to adults too.

    An employee review is supposed to help identify issues and increase employee performance, ultimately increasing productivity for the company. But a study found that companies that use 360 reviews, where colleagues and clients provide the feedback, saw a 10% drop in performance.

    Categories: Blogs

    All Features Implemented does not equal Project Success

    Dear Junior
    Setting goals for agile projects is trickier that setting goals for waterfall projects. As I mentioned in an earlier letter, for waterfall projects it is possible to set the goal in the form of a feature list to be delivered. This approach has several drawbacks - it does not guide the thousands of micro-decisions that are made, it gives no sense of purpose to support the drive or inner motivation, and it gives no guidance for evaluating whether the money, time, and effort was well spent.
    However, although all these problems, and although the approach is not advisable - it is still possible. The project management mindset and tools for waterfall projects are applicable for reporting project status or following up visavi a feature list. It is also possible to evaluate success by checking whether everything on the feature list is implemented.
    Well, I still think it would be better to evaluate whether the project created some value.
    Now, ridiculous as this seems it is still industry standard.
    The CHAOS report 1995 from Standish Group might be one of the most cited reports in system development. According to its statistics only 16% of software projects succeed. In the 2012 report this has been updated to 39%. And they collect data from tens of thousands of projects so the figures should be pretty reliable. 
    Now, this seems scary and low, but only until you check out their definition of success."Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified."OK. Not a word about actually getting value for the effort. Remember the on-line bookstore where they wanted others-have-bought recommendations to increase the number of books customers. Now, imagine they implemented the others-have-bought recommendations, but the customers did not buy more books anyway. Is this project a success?
    Well, you have spent lots of money building something, but made no money from it. To me it sounds like money, time, and effort down the drain - not as a success.
    To Standish Group, it is considered a success.
    On the flip side, imagine the project realising that a simplified "search similar" would increase the number of books each customer buys. Imagine further that this feature would be much easier to implement. So, the project decides to implement that feature instead. And the number of books sold per customer increases 0.4 on average.
    Spending less money, time, and effort on something else than originally envisioned, but still getting the benefit - that sounds like success to me.
    To Standish Group, it is considered a failure.
    Thus, the figure 16% or 39% actually says nothing at all about the state of software projects.
    So, Standish Group is probably filled with smart people. Why did they not evaluate software projects according to some meaningful metric instead? Most probably "generated business value as specified upon funding" would be more interesting. 
    My guess is that too few projects actually stated an envisioned business effect, so analysing those projects would give so little data that it would not be possible to make any significant conclusions.
    So, instead of measuring something that would actually matter ("fulfilled envisioned business effect") they just measured something that could be measured.
    Now, from the second example, where the team implemented another feature than originally envisioned, it is also clear that this approach is an absolutely worthless way of evaluating agile projects.  
    Yours
       Dan
    PS The way to measure agile projects is to set a target for a business effect.

    PS The CHAOS 1995 report has been republished openly available for academic purposes. It can be found at http://www.projectsmart.co.uk/docs/chaos-report.pdf. The 2013 version can be found at http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf

    Categories: Blogs

    Scaled Agile Framework: I Learned about Weighted Shorted Job First (WSJF)

    Learn more about our Scrum and Agile training sessions on WorldMindware.com

    Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items.  The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.

    Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done.  Scores therefore give a sequence to jobs.  The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”.  The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.

    In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners.  The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.

    Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
    facebooktwittergoogle_plusredditpinterestlinkedinmail
    Categories: Blogs

    Top 5 Mistakes for First Time Tech Leads

    thekua.com@work - Thu, 10/16/2014 - 13:28
    1. Spending too much time writing code

    Old habits die hard. When a developer suddenly steps into the Tech Lead role, it is not immediately clear what to do differently. Instead of taking on the Tech Lead responsibilities, they stay heads-down writing code. The more code they write, the better they feel that they are still contributing to the team. Other Tech Lead responsibilities are neglected in favour of writing code, even though they must still be fulfilled. A Tech Lead must spend enough time on non-coding responsibilities. They must ensure a Technical Vision exists, and the development team are working together towards the same goal. Both of these activities require more than just code-writing.

    2. Not spending enough time writing code

    The “Tech” in the Tech Lead role is there for a reason. It is too easy for a Tech Lead to sit in endless meetings instead of spending time with the team. They lose awareness of how the code is evolving and which patterns or anti-patterns emerge. Without an up-to-date awareness of the system and its technical constraints, a Tech Lead cannot effectively lead the team. A Tech Lead who codes has a better understanding of technical problems or opportunities whilst building and maintaining trust with developers. Writing code keeps the “Post Technical” label away.

    3. Making all the technical decisions

    The first time Tech Lead may feel compelled to make all decisions. To compensate for writing less code, or to demonstrate their new role, they give input to any and all decisions. Unfortunately this behaviour discourages the team from making contributions. It sends the message to the team they should do what they are told, or not think, even though a team member has the better solution to a particular problem. An effective Tech Lead knows when to give input, knows when to make decisions and when to step back and allow the team to take more ownership.

    4. Talking only Tech

    A Tech Lead interacts with many people who sit outside of the development team such as people from marketing, finance or a product division. These people usually have very limited technical knowledge. Talking to them in terms of frameworks, libraries and tools adds confusion, frustration and simultaneously signals a lack of empathy. A Tech Lead must find a way to communicate ideas in ways non-technical people can understand such as using analogies and using terms others can easily relate to.

    5. Constantly reacting

    A new Tech Lead will find themselves juggling several activities at once. The bane of a developer, interruptions, becomes an everyday occurrence. A first time Tech Lead can simply react to the loudest or most alarming situation, even if it is not the most important. Over time, the Tech Lead develops better time and task management skills in order to manage the many demands.

    If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

    Categories: Blogs

    Satisfaction

    Agile Tools - Thu, 10/16/2014 - 09:03

    As some of you may know, I’m building a boat in my brother’s garage. We had a big milestone the other day: we finished painting the bottom and rolled the boat over to finish the topsides. From a distance it looks great!

    Up close is another story though. Up close you can find ripples in the paint from where the fiberglass wasn’t sufficiently well sanded. There are other places where you can see fine lines in the paint due to underlying patterns in the filler compound. Add to that the fact that the paint has rough areas where the roller left a pattern. And don’t even get me started about that flat spot.

    I see all of these imperfections and more. It’s pretty rough.
    —–
    I’ve worked with teams like that too. From a distance, everything looks great. You are hitting your milestones and everyone is pleased.

    But get close and you find all sorts of flaws. They’re not using story points. They won’t keep their burn down chart up to date. They don’t even know what an acceptance test is. They’re pretty rough. Maybe we should just keep them in the garage…
    —–
    But around this time, along comes my brother. He takes one look at the boat and says, “Damn! That’s beautiful!” So I point out a flaw. He waves it off and says, “The only boat without scrapes and dents is in the showroom. This boat is going to sail!” Not to be dissuaded, I point out another flaw. He looks at me and says, “Will it float?”
    My answer, “Yes.”
    “OK then. Let’s get this thing in the water.”

    And so we go back to work, and somehow it is OK. I stop worrying and focus on what remains to be done.
    —–
    Sometimes someone visits the office. Someone I really respect and admire. I show them around and they say, “Wow, what a great team!” So I walk them over to the story board and point out that it’s out of date. They look at me and say, “That’s cool. Not many people even use physical dashboards.” I tell them that the team doesn’t use story points. They look at me and say, “Does the team deliver?”
    My answer, “Yes.”
    “OK then. Let’s sling some code.”
    —–
    And so I’m reminded not to be such a damn perfectionist.
    Love your boat.
    Love your team.


    Filed under: Agile, Coaching, Teams Tagged: perfection, Teams
    Categories: Blogs

    Generation Y: Wir wollen unser Leben genießen

    Scrum 4 You - Thu, 10/16/2014 - 07:56

    An vielen Ecken hört man es: die “Generation Y” will anders arbeiten. Die jungen, gut ausgebildeten Menschen zwischen 20 und 30 wollen einfach nicht mehr so hart rackern wie die Generation vor ihnen, heißt es. Und andererseits wissen die Vertreter der “Generation Me” (auch als Baby Boomer bezeichnet) nicht, wie sie im Job mit dieser Generation umgehen sollen. Nähern wir uns dem Thema Work-Life-Balance mit der Brille der “Generation Me”, dann verfällt man schnell der Idee, dass es neben der Arbeit noch etwas anderes geben sollte. Neben der Arbeit. Mich hat diese Trennung von Arbeit und Freitzeit immer gewundert. So als hätte man zwei Leben, als könne man jede Minute zweimal ausgeben: privat und beruflich.

    Generation Me: erfolgreich krank

    Woher kommt das Bedürfnis bei Menschen der Generation, der auch ich angehöre, nach dieser Work-Life-Balance? Vielleicht weil wir den Wohlstand, das zweite und das dritte Auto, damit erkauft haben. Wir haben sehr viel und sehr hart gearbeitet, denn harte Arbeit ist unser Statussymbol. Gleichzeitig haben wir nicht nur finanzielle Erfolge und Wohlstand erarbeitet: viele von uns haben sich im wahrsten Sinne des Wortes krank gearbeitet. Ich gebe es zu, auch ich bin bei zwei bis vier Flügen pro Woche und durch das ständige Schlafen in Hotels nicht so fit und gesund, wie ich es sein könnte. Auch die Zeitungen und Magazine sind voll von Berichten über unsere schwer erarbeiteten Zivilisationskrankheiten. Wäre ich, so wie viele andere, auch mit 30 Vater geworden, wäre meine Tochter oder mein Sohn jetzt schon 15 und würde sich zu Recht fragen, ob dieses Kaputtarbeiten irgendeinen Sinn hat und ob er oder sie das will. Ihre Antwort wäre natürlich: “Nein!” Und die Vertreter der Generation Y haben natürlich recht, sie müssen es auch gar nicht mehr.

    Langweilige Paradiese

    Ihre Eltern haben in vielen Unternehmen bereits die vollkommenen Paradiese geschaffen. Dort sind die Arbeitszeiten festgezogen, alles ist geregelt und wer freiwillig mehr leisten will, wird schief angeschaut (natürlich gilt das nicht in jedem Unternehmen). Gleichzeitig wird die Alterspyramide die Gehälter steigen lassen. Bei einer momentanen Geburtenrate von 1,34 in Österreich und der Tatsache, dass die Baby Boomer allmählich in Massen in Rente gehen, wächst der Wert der Arbeitskraft ins Gigantische.
    Gleichzeitig sind die großen Betriebe so durchgestylt, dass die Folge nur noch verwöhnte Langeweile sein kann. Wieso ich das sage?

    Ein Beispiel: Ich hatte einen Bewerber zum Interviewtermin, der aus der Automobilwirtschaft kommt. Heute 30 Jahre alt, Doktor der Soziologie, entscheidet er sich bewusst gegen die 35-Stunden-Arbeitswoche in einem großen deutschen Automobilkonzern. Die Arbeit dort ist nicht etwa zu anstrengend, sondern zu langweilig. Dort sind die Arbeitsabläufe geklärt, die Projektmanager verbringen ihre Zeit in stundenlangen Meetings, in denen doch nichts Wesentliches passiert, und der Effekt, also ihr Beitrag, ist gleich Null. Die Arbeit wird in Großunternehmen bzw. -konzernen sowieso von Dienstleistern erledigt – wie es Putzerfische bei einem Wal tun. Etwas bewegen, Sinn stiften und sich beweisen, dabei vielleicht auch scheitern und lernen, ist in diesen Unternehmen schwer geworden.

    Doch schauen wir mal dorthin, wo die eigentlichen Veränderungen derzeit passieren – nein, nicht bei Goolge und Co. Ganz ehrlich, eine Übermutter als Arbeitgeber, die mit ständig verfügbarem Essen, Massage und 1000 anderen Annehmlichkeiten aufwartet, wo Geld keine Rolle spielt und man machen kann, was man will, erzeugt kein Umfeld, in dem Innovation aufkommen kann. Der Spieltrieb wird angefacht, sicher, und es ist bestimmt ultracool, bei Google zu arbeiten. Aber mal ehrlich, welche Innovationen kamen von Google? Eine einzige! Ihre geniale Suche. Alles andere ist nachgebaut und bestenfalls optimiert. Google geht gerade den Weg der meisten großen Unternehmen: die Kreativität ist dahin, man beginnt, die Konkurrenz und die neuen Ideen zuzukaufen, statt selbst tolle Dinge zu machen.

    Neuer Realismus in der Arbeitswelt

    Wo ist also das Neue für die Arbeitswelt? Es beginnt immer am Rand. Da ist etwas Neues zu beobachten. Wahrscheinlich werden jetzt viele Trendforscher sagen: “alter Kaffee”, aber ich nehme gerade etwas vollkommen Neues wahr. Kleine Firmen, die weltweit verteilt sind und dank neuer Kommunikations- und Arbeitsinfrastrukturen wie Google Hangout, Skype und GitHub Bedingungen geschaffen haben, mit denen man als kleines Team weltweit miteinander arbeiten kann, beginnen tatsächlich ganz anders zu arbeiten.
    Da erzählen dann diese merkwürdigen Menschen aus der Generation Y, dass sie zuhause in ihren Wohnzimmern oder kleinen Arbeitszimmern sitzen, und gleichzeitig bei ihrer Familie sein können (Beispiele für diese Firmen sind: WordPress.com oder Bufferapp). Die Firmenmitglieder treffen sich ab und zu, um sich auch mal zu sehen, aber die Arbeit wird remote, verteilt und dezentralisiert gesteuert. Es entstehen dabei sogar neue Taskmanagement-Systeme, die tatsächlich ein neues Konzept verfolgen: IDoneThis. Sie zeigen, was gelungen ist, und nicht das, was man hätte tun sollen. Das ist eines der ersten Systeme, das mit einer vollkommen anderen Sicht entwickelt wurde. Hier ist es nicht vorgesehen, jemand anderem zu sagen, was er zu tun hat. Jeder sagt – offen – etwas darüber, was er getan hat. Ziemlich verrückt aus der Sicht der Generation ME. Work-Life-Balance spielt für die Generation Y keine Rolle mehr. Sie haben schon lange einen Weg gefunden, freier und viel realistischer mit ihrem Leben umzugehen.

    Related posts:

    1. Vacation is over – Vacation starts
    2. Prioritäten | Product Owners Tools
    3. Toyota Production System (4)

    Categories: Blogs

    Building Better Business Cases for Digital Initiatives

    J.D. Meier's Blog - Wed, 10/15/2014 - 19:26

    It’s hard to drive digital initiatives and business transformation if you can’t create the business case.  Stakeholder want to know what their investment is supposed to get them

    One of the simplest ways to think about business cases is to think in terms of stakeholders, benefits, KPIs, costs, and risks over time frames.

    While that’s the basic frame, there’s a bit of art and science when it comes to building effective business cases, especially when it involves transformational change.

    Lucky for us, in the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned in building better business cases for digital initiatives.

    What I like about their guidance is that it matches my experience

    Link Operational Changes to Tangible Business Benefits

    The more you can link your roadmap to benefits that people care about and can measure, the better off you are.

    Via Leading Digital:

    “You need initiative-based business cases that establish a clear link from the operational changes in your roadmap to tangible business benefits.  You will need to involve employees on the front lines to help validate how operational changes will contribute to strategic goals.”

    Work Out the Costs, the Benefits, and the Timing of Return

    On a good note, the same building blocks that apply to any business case, apply to digital initiatives.

    Via Leading Digital:

    “The basic building blocks of a business case for digital initiatives are the same as for any business case.  Your team needs to work out the costs, the benefits, and the timing of the return.  But digital transformation is still uncharted territory.  The cost side of the equation is easier, but benefits can be difficult to quantify, even when, intuitively, they seem crystal clear.”

    Start with What You Know

    Building a business case is an art and a science.   To avoid getting lost in analysis paralysis, start with what you know.

    Via Leading Digital:

    “Building a business case for digital initiatives is both an art an a science.  With so many unknowns, you'll need to take a pragmatic approach to investments in light of what you know and what you don't know.

    Start with what you know, where you have most of the information you need to support a robust cost-benefit analysis.  A few lessons learned from our Digital Masters can be useful.”

    Don’t Build Your Business Case as a Series of Technology Investments

    If you only consider the technology part of the story, you’ll miss the bigger picture.  Digital initiatives involves organizational change management as well as process change.  A digital initiative is really a change in terms of people, process, and technology, and adoption is a big deal.

    Via Leading Digital:

    “Don't build your business case as a series of technology investments.  You will miss a big part of the costs.  Cost the adoption efforts--digital skill building, organizational change, communication, and training--as well as the deployment of the technology.  You won't realize the full benefits--or possibly any benefits--without them.”

    Frame the Benefits in Terms of Business Outcomes

    If you don’t work backwards from the end-in-mind, you might not get there.  You need clarity on the business outcomes so that you can chunk up the right path to get there, while flowing continuous value along the way.

    Via Leading Digital:

    “Frame the benefits in terms of the business outcomes you want to reach.  These outcomes can be the achievement of goals or the fixing of problems--that is, outcomes that drive more customer value, higher revenue, or a better cost position.  Then define the tangible business impact and work backward into the levers and metrics that will indicate what 'good' looks like.  For instance, if one of your investments is supposed to increase digital customer engagement, your outcome might be increasing engagement-to-sales conversation.  Then work back into the main metrics that drive this outcome, for example, visits, like inquiries, ratings, reorders, and the like.

    When the business impact5 of an initiative is not totally clear, look at companies that have already made similar investments.  Your technology vendors can also be a rich, if somewhat biased, source of business cases for some digital investments.”

    Run Small Pilots, Evaluate Results, and Refine Your Approach

    To reduce risk, start with pilots to live and learn.   This will help you make informed decisions as part of your business case development.

    Via Leading Digital:

    “But, whatever you do, some digital investment cases will be trickier to justify, be they investments in emerging technologies or cutting-edge practices.  For example, what is the value of gamifying your brand's social communities?  For these types of investment opportunities, experiment with a test-and-learn approach.  State your measures of success, run small pilots, evaluate results, and refine your approach.  Several useful tools and methods exist, such as hypothesis-driven experiments with control groups, or A/B testing.  The successes (and failures) of small experiments can then become the benefits rationale to invest at greater scale.  Whatever the method, use an analytical approach; the quality of your estimated return depends on it.

    Translating your vision into strategic goals and building an actionable roadmap is the firs step in focusing your investment.  It will galvanize the organization into action.  But if you needed to be an architect to develop your vision, you need to be a plumber to develop your roadmap.  Be prepared to get your hands dirty.”

    While practice makes perfect, business cases aren’t about perfect.  Their job is to help you get the right investment from stakeholders so you can work on the right things, at the right time, to make the right impact.

    You Might Also Like

    Cloud Changes the Game from Deployment to Adoption

    How Digital is Changing Physical Experiences

    McKinsey on Unleashing the Value of Big Data Analytics

    Categories: Blogs

    Podcast with Cesar Abeid Posted

    Johanna Rothman - Wed, 10/15/2014 - 16:42

    Cesar Abeid interviewed me, Project Management for You with Johanna Rothman. We talked about my tools for project management, whether you are managing a project for yourself or managing projects for others.

    We talked about how to use timeboxes in the large and small, project charters, influence, servant leadership, a whole ton of topics.

    I hope you listen. Also, check out Cesar’s kickstarter campaign, Project Management for You.

    Categories: Blogs

    Scaled Agile Framework: I Learned about ROAM

    Learn more about our Scrum and Agile training sessions on WorldMindware.com

    The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM.  The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning.  ROAM stands for Resolved, Owned, Accepted, Mitigated.  The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them.  These risks are then place on a visible grid that has each of the four categories marked.  In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning.  Cool!

    Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
    facebooktwittergoogle_plusredditpinterestlinkedinmail
    Categories: Blogs

    News update 2014/10 – Why Coaching is Important

    ScrumSense.com - Peter Hundermark - Wed, 10/15/2014 - 10:49

    Coaching can make the difference between an organisation’s success or failure. In this month’s blog, Peter Hundermark outlines why effective coaching allows companies to admit their weaknesses and move towards a happier and more effective workplace. Read the full article here.

    Kanban PrinciplesKanban Training We have FOUR seats remaining on the upcoming Applying Kanban (Foundation) course taking place on the 20-21 Oct 2014 in Sandton. Be sure to book your place before these are snapped up. Should these dates not work for you, we will be running the course again on the 04-05 May 2015.

     

    We also still have a few spaces available on our upcoming Improving & Scaling Kanban (Advanced) course which will be taking place in Sandton on the 23-24 Oct 2014. We are running a 3-for-2 special offer on both the certified Foundation and Advanced courses, so be sure to secure your place!

     

    Interesting Links

    InfoQ Publications

    InfoQ have published the remaining two articles in the series from the short book “Leading Self-Organising Teams” written by Dr. Sigi Kaltenecker & Peter Hundermark. Have a read of these articles: “why do we need self-organising teams?” and “what is Leading Self-Organising Teams all about?

    Q&A Teleconferences

    Esther Derby is offering free Q&A teleconferencing sessions. Each month Esther chooses a topic which will be of interest to people who coach, manage, or work on software teams. Follow this link to sign up. Upcoming Courses Applying Kanban (Foundation) – (JHB) – Only 4 seats left!
    20-21 Oct 2014
    FNB Conference & Learning Centre, Sandton

     

    Improving & Scaling Kanban (Advanced) – (JHB)
    23-24 Oct 2014
    FNB Conference & Learning Centre, Sandton

     

    Certified Scrum Product Owner (JHB) – Fully booked!
    04 – 05 Nov 2014
    FNB Conference & Learning Centre, Sandton

     

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

     

    Course schedule and Book Online

    The post News update 2014/10 – Why Coaching is Important appeared first on ScrumSense.

    Categories: Blogs