Skip to content

Feed aggregator

Successful Digital Vision Starts at the Top

J.D. Meier's Blog - Thu, 03/05/2015 - 18:49

Business change is tough.   Just try it at Cloud speed, and you’ll know what I mean.

That said, digital business transformation is reshaping companies and industries around the world, at a rapid rate.

If you don’t cross the Cloud chasm, and learn how to play in the new digital economy,  you might just get left behind.

Sadly, not every executive has a digital vision.

That’s a big deal because the pattern here is that successful digital business transformation starts at the top of the company.  And it starts with digital vision.

But just having a digital vision is not enough.

It has to be a shared transformative digital vision.   Not a mandate, but a shared digital vision from the top, that’s led and made real by the people in the middle and lower levels.

In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share how successful companies and executives drive digital business transformation through shared transformative digital visions.

Employees Don’t Always Get the WHY, WHAT, or HOW of Digital Business Transformation

You need a digital vision at the top.   Otherwise, it’s like pushing rocks uphill.  Worse, not everybody will be in the game, or know what position they play, or even how to play the game.

Via Leading Digital: Turning Technology into Business Transformation:

“The changes being wrought through digital transformation are real.  Yet, even when leaders see the digital threats and opportunity, employees may need to be convinced.  Many employees feel they are paid to do a job, not to change that job.  And they have lived through big initiatives in the past that failed to turn into reality.  To many, digital transformations is either irrelevant or just another passing fad.  Still other people may not understand how the change affects their jobs or how they might make the transition.”

Only Senior Executives Can Create a Compelling Vision of the Future

Digital business transformation must be led.   Senior executives are in the right position to create a compelling future all up, and communicate it across the board.

Via Leading Digital: Turning Technology into Business Transformation:

“Our research shows that successful digital transformation starts at the top of the company.  Only the senior-most executives can create a compelling vision of the future and communicate it throughout the organization.  Then people in the middle and lower levels can make the vision a reality.  Managers can redesign process, workers can start to work differently, and everyone can identify new ways to meet the vision.  This kind of change doesn't happen through simple mandate.  It must be led.

Among the companies we studied, none have created true digital transformation through a bottom-up approach.  Some executives have changed their parts of the business--for example, product design and supply chain at Nike--but the executives stopped at the boundaries of their business units.  Changing part of your business is not enough.  Often, the real benefits of transformation come from seeing potential synergies across silos and then creating conditions through which everyone can unlock that value.  Only senior executives are positioned to drive this kind of boundary-spanning change.”

Digital Masters Have a Shared Digital Vision (While Others Do Not)

As the business landscape is reshaping, you are either a disruptor or the disrupted.  The Digital Masters that are creating the disruption in their business and in their industries have shared digital visions, and re-imagine their business for a mobile-first, Cloud-first world, and a new digital economy.

Via Leading Digital: Turning Technology into Business Transformation:

“So how prevalent is digital vision? In our global survey of 431 executives in 391 companies, only 42 percent said that their senior executive had a digital vision.  Only 35 percent said the vision was shared among senior and middle managers.  These numbers are surprisingly low, given the rapid rate at which digital transformation is reshaping companies and industries.  But the low overall numbers mask an important distinction.  Digital Masters have a shared digital vision, while others do not. 

Among the Digital Masters that we surveyed, 82 percent agreed that their senior leaders shared a common vision of digital transformation, and 71 percent said it was shared between senior and middle managers.  The picture is quite different for firms outside our Digital Masters category, where less than 30 percent said their senior leaders had a shared digital vision and only 17 percent said the shared vision extended to middle management.”

Digital Vision is Not Enough (You Need a Transformative Digital Vision)

It’s bad enough that many executives don’t have a shared digital vision.   But what makes it worse, is that even fewer have a transformative digital vision, which is the key to success in the digital frontier.

Via Leading Digital: Turning Technology into Business Transformation:

“But having a shared digital vision is not quite enough.  Many organizations fail to capture the full potential of digital technologies because their leaders lack a truly transformative vision of the digital future.  On average, only 31 percent of our respondents said that they had a vision which represented radical change, and 41 percent said their vision crossed internal organizational units.  Digital Masters were far more transformative in their vision, with two-thirds agreeing they had a radical vision, and 82 percent agreeing their vision crossed organizational silos.  Meanwhile, nonmasters were far less transformative in their visions.”

Where there is no vision, the businesses perish.

You Might Also Like

Cloud Changes the Game from Deployment to Adoption

Drive Business Transformation by Reenvisioning Operations

Drive Business Transformation by Reenvisioning Your Customer Experience

Dual-Speed IT Drives Business Transformation and Improves IT-Business Relationships

How Leaders are Building Digital Skills

How To Build a Better Business Case for Digital Initiatives

How To Improve the IT-Business Relationship

How To Build a Roadmap for Your Digital Business Transformation

Categories: Blogs

No Time to Learn

George Dinwiddie’s blog - Thu, 03/05/2015 - 18:46

The number one problem I see at clients is that there is no time to learn. Without time to reflect on how things are working, we don’t notice the things that we’re accustomed to not working very well. Without time to research what others are doing, we can’t make informed choices about things we might want to try. Without time to try experiments, we can’t find out if a different approach will work better for us, or not. Without time to try multiple experiments, we can’t evaluate what works for us over a broad range of situations rather than latching onto the first idea that appears to work at all.

To a large degree, Agile software development IS learning. We try things mindfully, watch the results we get, reflect on why we get those results, and adjust. We do that at multiple levels of granularity, from choosing what products to develop to writing code that works reliably.

It takes time, but it pays off over time. To keep doing the same things in the same way suggests that we know everything there is to know about it, and there are no improvements left to make. That we are already at top speed. That we can only do worse than we are right now. I find that highly unlikely.

There is always more to learn. There are ways to learn better ways to learn.

Categories: Blogs

Scrum Alliance Opens 2015 State of Scrum Survey - Thu, 03/05/2015 - 18:12
The Scrum Alliance, the largest, most established and influential professional membership organization and certifying body in the Agile community, announces the opening of its biennial State of Scrum Survey, which gives the Scrum community deeper insight into the progress and adoption of Agile a ...
Categories: Communities

State of Scrum Survey Launched by Scrum Alliance

Scrum Expert - Thu, 03/05/2015 - 18:07
The Scrum Alliance has announced the opening of its biennial 2015 State of Scrum Survey, which gives the Scrum community deeper insight into the progress and adoption of Agile and Scrum processes. “We published the first State of Scrum report in 2013, and it’s a very popular benchmark report. Those interested in Scrum simply want unbiased data about who is using Scrum, why, and how, and that’s what we deliver in this report,” explains Scrum Alliance Managing Director Carol McEwan. The purpose of the State of Scrum report is to track trends ...
Categories: Communities

New Video Series: Kanban in One Minute by Michael Badali

Learn more about our Scrum and Agile training sessions on

Check out our first video “Kanban Basics”.

Michael Badali is a Kanban expert with years of experience in Kanban and other Agile methods including nearly 2 years working as an internal coach at HP in China and the UK.

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!
Categories: Blogs

Python: scikit-learn/lda: Extracting topics from QCon talk abstracts

Mark Needham - Thu, 03/05/2015 - 10:52

Following on from Rik van Bruggen’s blog post on a QCon graph he’s created ahead of this week’s conference, I was curious whether we could extract any interesting relationships between talks based on their abstracts.

Talks are already grouped by their hosting track but there’s likely to be some overlap in topics even for talks on different tracks.
I therefore wanted to extract topics and connect each talk to the topic that describes it best.

My first attempt was following an example which uses Non-Negative Matrix factorization which worked very well for extracting topics but didn’t seem to provide an obvious way to work out how to link those topics to individual talks.

Instead I ended up looking at the lda library which uses Latent Dirichlet Allocation and allowed me to achieve both goals.

I already had some code to run TF/IDF over each of the talks so I thought I’d be able to feed the matrix output from that into the LDA function. This is what I started with:

import csv
from sklearn.feature_extraction.text import TfidfVectorizer, CountVectorizer
from sklearn.decomposition import NMF
from collections import defaultdict
from bs4 import BeautifulSoup, NavigableString
from soupselect import select
def uri_to_file_name(uri):
    return uri.replace("/", "-")
sessions = {}
with open("data/sessions.csv", "r") as sessions_file:
    reader = csv.reader(sessions_file, delimiter = ",") # header
    for row in reader:
        session_id = int(row[0])
        filename = "data/sessions/" + uri_to_file_name(row[4])
        page = open(filename).read()
        soup = BeautifulSoup(page)
        abstract = select(soup, "div.brenham-main-content p")
        if abstract:
            sessions[session_id] = {"abstract" : abstract[0].text, "title": row[3] }
            abstract = select(soup, "div.pane-content p")
            sessions[session_id] = {"abstract" : abstract[0].text, "title": row[3] }
corpus = []
titles = []
for id, session in sorted(sessions.iteritems(), key=lambda t: int(t[0])):
n_topics = 15
n_top_words = 50
n_features = 6000
vectorizer = TfidfVectorizer(analyzer='word', ngram_range=(1,1), min_df = 0, stop_words = 'english')
matrix =  vectorizer.fit_transform(corpus)
feature_names = vectorizer.get_feature_names()
import lda
import numpy as np
vocab = feature_names
model = lda.LDA(n_topics=20, n_iter=500, random_state=1)
topic_word = model.topic_word_
n_top_words = 20
for i, topic_dist in enumerate(topic_word):
    topic_words = np.array(vocab)[np.argsort(topic_dist)][:-n_top_words:-1]
    print('Topic {}: {}'.format(i, ' '.join(topic_words)))

And if we run it?

Topic 0: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 1: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 2: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 3: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 4: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 5: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 6: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 7: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 8: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 9: 10 faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 10: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 11: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 12: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 13: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 14: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 15: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 16: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 17: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 18: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure
Topic 19: zoosk faced exposing expression external externally extra extraordinary extreme extremes face facebook facilitates faster factor factors fail failed failure

As you can see, every topic has the same set of words which isn’t what we want. Let’s switch out our TF/IDF vectorizer for a simpler count based one:

vectorizer = CountVectorizer(analyzer='word', ngram_range=(1,1), min_df = 0, stop_words = 'english')

The rest of the code stays the same and these are the topics that get extracted:

Topic 0: time people company did writing real way used let cassandra soundcloud successful know web organization audio lives swift stuck
Topic 1: process development delivery platform developer continuous testing rapidly deployment implementing release demonstrate paas advice hard light predictable radically introduce
Topic 2: way open space kind people change meetings ll lead powerful practice times everyday simple qconlondon organization unconference track extraordinary
Topic 3: apache apis processing open spark distributed leading making environments solr cases brooklyn components existing ingestion contributing data target evolved
Topic 4: management million effective cost halo gameplay player billion ad catastrophic store microsoft final music influence information launch research purchased
Topic 5: product look like use talk problems working analysis projects challenges 2011 functionality useful spread business deep inside happens sensemaker
Topic 6: ll computers started principles free focus face smaller atlas control uses products avoid computing ground billions mean volume consistently
Topic 7: code end users developers just application way line apps mobile features sites hours issues applications write faster game better
Topic 8: ve development teams use things world like time learned lessons think methods multiple story say customer developer experiences organisations
Topic 9: software building docker built challenges monitoring gilt application discuss solution decision talk download source center critical decisions bintray customers
Topic 10: years infrastructure tools language different service lot devops talk adoption scala popular clojure advantages introduced effectively looking wasn includes
Topic 11: high does latency session requirements functional performance real world questions problem second engineering patterns gravity explain discuss expected time
Topic 12: business make build technology technologies help trying developers parts want interfaces small best centres implementations critical moo databases going
Topic 13: need design systems large driven scale software applications slow protocol change needs approach gets new contracts solutions complicated distributed
Topic 14: architecture service micro architectures increasing talk microservices order market value values new present presents services scalable trading practices today
Topic 15: java using fast robovm lmax ios presentation really jvm native best exchange azul hardware started project slowdowns goal bring
Topic 16: data services using traditional create ways support uk large user person complex systems production impact art organizations accessing mirage
Topic 17: agile team experience don work doing processes based key reach extra defined pressure machines nightmare practices learn goals guidance
Topic 18: internet new devices programming things iot big number deliver day connected performing growing got state thing provided times automated
Topic 19: cloud including deploy session api government security culture software type attack techniques environment digital secure microservice better creation interaction

Some of the groupings seem to make sense e.g. Topic 11 contains words related to high performance code with low latency; Topic 15 covers Java, the JVM and other related words; but others are more difficult to decipher

e.g. both Topic 14 and Topic 19 talk about micro services but the latter mentions ‘government’ and ‘security’ so perhaps the talks linked to that topic come at micro services from a different angle altogether.

Next let’s see which topics a talk is most likely to be about. We’ll look at the first ten:

doc_topic = model.doc_topic_
for i in range(0, 10):
    print("{} (top topic: {})".format(titles[i], doc_topic[i].argmax()))
To the Moon (top topic: 8)
[ 8  0 11]
Evolutionary Architecture and Micro-Services - A Match Enabled by Continuous Delivery (top topic: 14)
[14 19 16]
How SoundCloud uses Cassandra (top topic: 0)
[0 6 5]
DevOps and the Need for Speed (top topic: 18)
[18  5 16]
Neuro-diversity and agile (top topic: 7)
[17  7  2]
Java 8 in Anger (top topic: 7)
[ 7 15 12]
APIs that Change Lifestyles (top topic: 9)
[ 9  6 19]
Elasticsearch powers the Citizen Advice Bureau (CAB) to monitor trends in society before they become issues (top topic: 16)
[16 12 19]
Architecture Open Space (top topic: 2)
[ 2 19 18]
Don’t let Data Gravity crush your infrastructure (top topic: 11)
[11 16  3]

So our third talk on the list ‘How SoundCloud uses Cassandra’ does end up being tagged with topic 0 which mentions SoundCloud so that’s good!

Topic 0: time people company did writing real way used let cassandra soundcloud successful know web organization audio lives swift stuck

It’s next two topics are 5 & 6 which contain the following words…

Topic 5: product look like use talk problems working analysis projects challenges 2011 functionality useful spread business deep inside happens sensemaker
Topic 6: ll computers started principles free focus face smaller atlas control uses products avoid computing ground billions mean volume consistently

…which are not as intuitive. What about Java 8 in Anger? It’s been tagged with topics 7, 15 and 12:

Topic 7: code end users developers just application way line apps mobile features sites hours issues applications write faster game better
Topic 15: java using fast robovm lmax ios presentation really jvm native best exchange azul hardware started project slowdowns goal bring
Topic 12: business make build technology technologies help trying developers parts want interfaces small best centres implementations critical moo databases going

15 makes sense since that mentions Java and perhaps 12 and 7 do as well as they both mention developers.

So while the topics pulled out are not horrendous I don’t think they’re particularly useful yet either. These are some of the areas I need to do some more research around:

  • How do you measure the success of topic modelling? I’ve been eyeballing the output of the algorithm but I imagine there’s an automated way to do that.
  • How do you determine the right number of topics? I found an article written by Christophe Grainger which explains a way of doing that which I need to look at in more detail.
  • It feels like I would be able to pull out better topics if I had an ontology of computer science/software words and then ran the words through that to derive topics.
  • Another approach suggested by Michael is to find the most popular words using the CountVectorizer and tag talks with those instead.

If you have any suggestions let me know. The full code is on github if you want to play around with it.

Categories: Blogs

When Will We Complete Our Agile Transformation?

Leading Agile - Mike Cottmeyer - Wed, 03/04/2015 - 17:53

People tend to ask me the general question of how long it will take to complete an Agile transformation.  Unless I’m responding to my son, in which the answer would be “5 more minutes”, my answer would be “it depends”. It’s just the reality, based on so many variables. At LeadingAgile, we describe the journey of a transformation as successfully getting a pilot group (expedition) from basecamp to basecamp. We then follow with other groups, when the path is clear and well maintained.

Let’s say you’re planning a long hike on the Appalachian Trail or climbing Mount Everest (transformation analogy). To calculate the time to complete the journey, the first thing I would look at on the trail map is the distance (to my final destination goal), then the elevation changes to my basecamps or resupply points, then I would look at the weather conditions.

Trail Map

Look at the graphic at the bottom of our compass page to visualize what I’m saying.  If you know where you are and know where you want to be, with mountaineering you are fortunate to look at the map, see your latitude, longitude, and elevation, and know if you’ve made it to your destination.  With Agile transformations, the coordinates on a map are actually your adoption levels in four of the five competency areas defined in our assessments: Defining the product, planning and coordinating, delivering solutions, and continuous improvement.  We’ll talk about the fifth competency area, organizational enablement, in a little bit.


If you were climbing Mount Everest, there are two basecamps, one on each side of the mountain. They are basic encampments for providing supplies, shelter, and communications for persons engaged in the trek. Supplies are carried to the basecamp by sherpas or porters (in our case it will be one or more of our guides). The criteria to reach each basecamp is different, depending on the destination. Using our compass, we know where you are, know where you are going, and know what gear you are going to need.  Though I know you want to reach your final destination, focus on reaching the next basecamp safely is critical.  Your transformation will fail, if you can’t get your team safely to a basecamp.

Weather Conditions

I see going from basecamp to basecamp as a change of location and elevation or a change in behaviour and outcomes within your organization.  The expedition will have to get used to operating at different elevations. But weather conditions are much more unpredictable.  If the weather conditions were unfavorable, and I have a long trek ahead to the next basecamp or summit, it could make an expedition harder than it need be or downright impossible. How do I know the current weather conditions? In our assessment, I use Organizational Enablement.

Organizational Enablement

In order for teams to improve in the other competency areas (reach basecamps), they should also improve in areas of organizational enablement.  If an organization refuses to form teams, provide a supportive organizational context, or ignore a series of other elements, it would be like walking into a blizzard in summer.  It’s going to slow you down to a crawl or stop you dead in your tracks.

In order for change to occur in your organization, you must enable it to happen.  Want to know how long it will take to complete an Agile Transformation?  I think you need to listen to your guide but you also need to control the weather.

The post When Will We Complete Our Agile Transformation? appeared first on LeadingAgile.

Categories: Blogs

how I earned $1,000 / hr

Derick Bailey - new ThoughtStream - Wed, 03/04/2015 - 13:00

During the week of February 16th-20th (2015), I spent approximately 3 hours writing a few emails and one web page. The week after that, brought in just over $3,000 of income from those emails and that page.

How did that happen?! How was I able to earn $1,000/hr for the work I did?!



A Few Small Wins, A Home Run!

Not quite a year ago, I moved my screencast site to a subscription service. Previously, you could only buy individual screencasts or bundled packages. With the new model, you could only pay a monthly subscription to access to everything. This has worked out pretty well for me. There have been rough spots, but over-all, it has provided a steady level of income for me.

But over time, I started getting more and more requests to be able to buy individual screencasts, or packages of screencasts – the way things used to be. Recognizing the “Shut up and take my money!” that I was hearing, I found a way to do the subscription model as well as bundled packages.

I released my first bundle the week before Christmas, 2014. Sales were ok. I think I hit 20 total for the week, and brought in about $800. Then in January, I released another screencast bundle and it didn’t do quite as well. I sold not quite 20 copies and brought in around $600. Still, this wasn’t bad. I was only spending a handful of hours on putting the bundles together.

Through these first two bundle sales and the feedback that I was getting, I realized something very important about my products. Not everyone was able to, or willing to, pay for a monthly subscription. People still wanted to have access to my screencasts, though. And once I started making them available to everyone – both on a monthly subscription basis, and on a one-time-sale basis – I was able to increase my customer base significantly!

All of this leads me up to the last week of February, 2015 – that’s when I hit my first real home run with these screencast bundles, bringing in more than $3,000 for approximately 3 hours of work.


Over the last however-many-months, I saw people asking for something and I wondered if I could provide that thing – a different way to obtain the screencasts that I was producing.  This was something I had done before, so I found a way to make it work easily with my new site setup. The result was my being able to leverage existing content – content that I had already produced for my monthly subscribers – and sell that content in a different way, more than doubling my revenue for the month of February.

Leverage is a powerful thing – and it’s something that my friend John Sonmez has been talking about lately. He’s done an amazing job of leveraging his work to find new opportunities and new ways to promote that work. From podcast appearances, to articles in major websites, John has re-packaged and re-used content that he had already produced, and has been able to earn more traffic and more income from his products because of this.

Finding the right place to apply pressure can be the difference between success and failure. Leverage can help you lift an impossibly heavy object with little effort, double your website’s traffic, or help you earn $1,000 / hr.

Leverage Is Hard Work

While it’s great to talk about leverage and see the amazing effects that it can have, there’s a lot of hard work to get to that point.

John spent months of full time work writing his Soft Skills book (a book that I believe should be on every developer’s desk, by the way). It was only through the efforts that he put in to this book, that he was able to create the leverage he needed.

I have spent years creating screencasts, and put hours of effort in to each screencast I produce. I had already done the work of producing and release my screencasts on my subscription service. It was only because I had done this work, that I was able to create the leverage that I needed.

There are no shortcuts to creating leverage. It requires hard work, paying attention to your audience, persistence, and more work. But if you can find a way to make your efforts profitable in the first place, then you may also find yourself looking at a point of leverage on which you can lean.

Want To Earn $1,000 Today?

Charles Max Wood said this to me, after my first day of sales on February 23rd:

Want to earn $1000 today? You can (a) consult 6.5 hours at $150/hour or (b) sell stuff you’ve already made in a different way.

I put in the hard work. I kept at it, in spite of my desire to throw in the towel and quit. And when my point of leverage was presented to me, I chose option (b) and earned $1,000 because of it.

– Derick

Categories: Blogs

ScrumImpulz, Bratislava, Slovakia, April 29 2015

Scrum Expert - Tue, 03/03/2015 - 18:43
ScrumImpulz is a one-day conference focused on Scrum that takes place in Bratislava, Slovakia. Local and international experts share their practical experience about the adoption of Agile approaches in software development projects. In the agenda of the ScrumImpulz you could find topics like “Management 3.0 – model for agile leaders”, “The worst fails that can occur in our agile team and how to deal with them”, “Global challenges require responses. People and teamwork are the best one” and a case study on Agile in the software development department of an international ...
Categories: Communities

From Software Development to Problem Solving

Scrum Expert - Tue, 03/03/2015 - 18:35
Agile and Scrum short iterations should provide software development organization with quicker feedback cycles and help them shifting from building the product right to building the right product. In their book “The Lean Mindset”, Mary and Tom Poppendieck provides an original perspective on this issue. What’s next is to stop thinking about software development as a delivery process and to start thinking of it as a problem-solving process, a creative process. Time and again we run into software delivery organizations – IT departments operating as cost centers and software firms working ...
Categories: Communities

The 5 Stages Of Entrepreneurial Grief: A Presentation and Video

Derick Bailey - new ThoughtStream - Tue, 03/03/2015 - 17:41

A while back, I wrote a blog post title The 5 Stages of a SaaS Bootstrapper’s Grief. In this post, I add my own take on the 5 Stages of Grief – which are typically talked about in the context of dealing with loss – and apply the stages to entrepreneurial work.

On March 2nd, 2015 I had the opportunity to turn that blog post in to a presentation for the PrairieDevCon 2015 conference. I recorded the talk and have uploaded it to YouTube for everyone to watch.

In this talk, I go through not only the 5 stages of grief, as applied to entrepreneurial work, but also add my own “Stage 0: Frenetic Energy” as well as some additional lessons learned.

If you’re interested in building your own products and/or services, and are wondering what the reality of trying to sell things is really like, you should watch this video.

Resources From The Talk

Along with this talk, I reference a number of resources and links. I also have the slide deck and all of the images from it available on Github. Check out the resources here:


Categories: Blogs

101 Proven Practices for Focus

J.D. Meier's Blog - Tue, 03/03/2015 - 17:30

“Lack of direction, not lack of time, is the problem. We all have twenty-four hour days.” -- Zig Ziglar

Here is my collection of 101 Proven Practices for Focus.   It still needs work to improve it, but I wanted to shared it, as is, because focus is one of the most important skills we can develop for work and life.

Focus is the backbone of personal effectiveness, personal development, productivity, time management, leadership skills, and just about anything that matters.   Focus is a key ingredient to helping us achieve the things we set out to do, and to learn the things we need to learn.

Without focus, we can’t achieve great results.

I have a very healthy respect for the power of focus to amplify impact, to create amazing breakthroughs, and to make things happen.

The Power of Focus

Long ago one of my most impactful mentors said that focus is what separates the best from the rest.  In all of his experience, what exceptional people had, that others did not, was focus.

Here are a few relevant definitions of focus:
A main purpose or interest.
A center of interest or activity.
Close or narrow attention; concentration.

I think of focus simply as  the skill or ability to direct and hold our attention.

Focus is a Skill

Too many people think of focus as something either you are good at, or you are not.  It’s just like delayed gratification.

Focus is a skill you can build.

Focus is actually a skill and you can develop it.   In fact, you can develop it quite a bit.  For example, I helped a colleague get themselves off of their ADD medication by learning some new ways to retrain their brain.   It turned out that the medication only helped so much, the side effects sucked, and in the end, what they really needed was coping mechanisms for their mind, to better direct and hold their attention.

Here’s the surprise, though.  You can actually learn how to direct your attention very quickly.  Simply ask new questions.  You can direct your attention by asking questions.   If you want to change your focus, change the question.

101 Proven Practices at a Glance

Here is a list of the 101 Proven Practices for Focus:

  1. Align  your focus and your values
  2. Ask new questions to change your focus
  3. Ask yourself, “What are you rushing through for?”
  4. Beware of random, intermittent rewards
  5. Bite off what you can chew
  6. Breathe
  7. Capture all of your ideas in one place
  8. Capture all of your To-Dos all in one place
  9. Carry the good forward
  10. Change your environment
  11. Change your physiology
  12. Choose one project or one thing to focus on
  13. Choose to do it
  14. Clear away all distractions
  15. Clear away external distractions
  16. Clear away internal distractions
  17. Close your distractions
  18. Consolidate and batch your tasks
  19. Create routines to help you focus
  20. Decide to finish it
  21. Delay gratification
  22. Develop a routine
  23. Develop an effective startup routine
  24. Develop an effective shutdown routine
  25. Develop effective email routines
  26. Develop effective renewal activities
  27. Develop effective social media routines
  28. Direct your attention with skill
  29. Do less, focus more
  30. Do now what you could put off until later
  31. Do things you enjoy focusing on
  32. Do worst things first
  33. Don’t chase every interesting idea
  34. Edit later
  35. Exercise your body
  36. Exercise your mind
  37. Expand your attention span
  38. Find a way to refocus
  39. Find the best time to do your routine tasks
  40. Find your flow
  41. Finish what you started
  42. Focus on what you control
  43. Force yourself to focus
  44. Get clear on what you want
  45. Give it the time and attention it deserves
  46. Have a time and place for things
  47. Hold a clear picture in your mind of what you want to accomplish
  48. Keep it simple
  49. Keep your energy up
  50. Know the tests for success
  51. Know what’s on your plate
  52. Know your limits
  53. Know your personal patterns
  54. Know your priorities
  55. Learn to say no – to yourself and others
  56. Limit your starts and stops
  57. Limit your task switching
  58. Link it to good feelings
  59. Make it easy to pick back up where you left off
  60. Make it relentless
  61. Make it work, then make it right
  62. Master your mindset
  63. Multi-Task with skill
  64. Music everywhere
  65. Narrow your focus
  66. Pair up
  67. Pick up where you left off
  68. Practice meditation
  69. Put the focus on something bigger than yourself
  70. Rate your focus each day
  71. Reduce friction
  72. Reduce open work
  73. Reward yourself along the way
  74. See it, do it
  75. Set a time frame for focus 
  76. Set goals
  77. Set goals with hard deadlines
  78. Set mini-goals
  79. Set quantity limits
  80. Set time limits
  81. Shelve things you aren’t actively working on
  82. Single Task
  83. Spend your attention with skill
  84. Start with WHY
  85. Stop starting new projects
  86. Take breaks
  87. Take care of the basics
  88. Use lists to avoid getting overwhelmed or overloaded
  89. Use metaphors
  90. Use Sprints to scope your focus
  91. Use the Rule of Three
  92. Use verbal cues
  93. Use visual cues
  94. Visualize your performance
  95. Wake up at the same time each day
  96. Wiggle your toes – it’s a fast way to bring yourself back to the present
  97. Write down your goals
  98. Write down your steps
  99. Write down your tasks
  100. Write down your thoughts
  101. Work when you are most comfortable

When you go through the 101 Proven Practices for Focus, don’t expect it to be perfect.  It’s a work in progress.   Some of the practices for focus need to be fleshed out better.   There is also some duplication and overlap, as I re-organize the list and find better ways to group and label ideas.

In the future, I’m going to revamp this collection to have some more precision, better naming, and some links to relevant quotes, and some science where possible.   There is a lot more relevant science that explains why some of these techniques work, and why some work so well.

What’s important is that you find the practices that resonate for you, and the things that you can actually practice.

Getting Started

You might find that from all the practices, only one or two really resonate, or help you change your game.   And, that’s great.   The idea of having a large list to select from is that it’s more to choose from.  The bigger your toolbox, the more you can choose the right tool for the job.  If you only have a hammer, then everything looks like a nail.

If you don’t consider yourself an expert in focus, that’s fine.  Everybody has to start somewhere.  In fact, you might even use one of the practices to help you get better:  Rate your focus each day.

Simply rate yourself, on a scale of 1-10, where 10 is awesome and 1 means you’re a squirrel with a sugar high, dazed and confused, and chasing all the shiny objects that come into site.   And then see if your focus improves over the course of a week.

If you adopt just one practice, try either Align  your focus and your values or Ask new questions to change your focus.  

Feel Free to Share It With Friends

At the bottom of the 101 Proven Practices for Focus, you’ll find the standard sharing buttons for social media to make it easier to share.

Share it with friends, family, your world, the world.

The ability to focus is really a challenge for a lot of people.   The answer to improve your attention and focus is through proven practices, techniques, and skill building.  Too many people hope the answer lies in a pill, but pills don’t teach you skills.

Even if you struggle a bit in the beginning, remind yourself that growth feels awkward.   You' will get better with practice.  Practice deliberately.  In fact, the side benefit of focusing on improving your focus, is, well, you guessed it … you’ll improve your focus.

What we focus on expands, and the more we focus our attention, and apply deliberate practice, the deeper our ability to focus will grow.

Grow your focus with skill.

You Might Also Like

The Great Inspirational Quotes Revamped

The Great Happiness Quotes Collection Revamped

The Great Leadership Quotes Collection Revamped

The Great Love Quotes Collection Revamped

The Great Motivational Quotes Revamped

The Great Personal Development Quotes Collection Revamped

The Great Positive Thinking Quotes Collection

The Great Productivity Quotes Collection Revamped

Categories: Blogs

A product manager's perfection....

Xebia Blog - Tue, 03/03/2015 - 16:59

is achieved not there are no more features to add, but when there are no more features to take away. -- Antoine de Saint Exupéry

Not only was Antoine a brilliant writer, philosopher and pilot (well arguably since he crashed in the Mediterranean) but most of all he had a sharp mind about engineering, and I frequent quote him when I train product owners, product managers or in general product companies, about what makes a good product great. I also tell them their most important word in their vocabulary is "no". But the question then becomes, what is the criteria to say "yes"?

Typically we will look at the value of a feature and use different ways to prioritise and rank different features, break them down to their minimal proposition and get the team going. But what if you already have a product? and it’s rate of development is slowing. Features have been stacked on each other for years or even decades, and it’s become more and more difficult for the teams to wade through the proverbial swamp the code has become?

Too many features

Too many features

Turns out there are a number of criteria that you can follow:

1.) Working software, means it’s actually being used.

Though it may sound obvious, it’s not that easy to figure out. I was once part of a team that had to rebuild a rather large piece (read huge) of software for an air traffic control system. The managers ensured us that every functionality was a must keep, but the cost would have been prohibitory high.

One of the functions of the system was a record and replay mode for legal purposes. It basically registers all events throughout the system to serve as evidence that picture compilers would be accountable, or at least verifiable. One of our engineers had the bright insight that we could catalogue this data anonymously to figure out which functions were used and which were not.

Turned out the Standish Group was pretty right in their claims that 80% of the software is never used. Carving that out was met with fierce resistance, but it was easier to convince management (and users) with data, than with gut.

Another upside? we also knew what functions they were using a lot, and figured out how to improve those substantially.

2.) The cost of platforms

Yippee we got it running on a gazillion platforms! and boy do we have a reach, the marketing guys are going frenzy. Even if is the right choice at the time, you need to revisit this assumption all the time, and be prepared to clean up! This is often looked upon as a disinvestment: “we spent so much money on finally getting Blackberry working” or “It’s so cost effective that we can also offer it on platform XYZ”.

In the web world it’s often the number of browsers we support, but for larger software systems it is more often operating systems, database versions or even hardware. For one customer we would refurbish hardware systems, simply because it was cheaper than moving on to a more modern machine.

Key take away: If the platform is deprecated, remove it entirely from the codebase, it will bog the team down and you need their speed to respond to an ever increasing pace of new platforms.

3.) Old strategies

Every market and every product company pivots at least every few years (or dies). Focus shifts from consumer groups, to type of clients, type of delivery, shift to service or something else which is novel, hip and most of all profitable. Code bases tend to have a certain inertia. The larger the product, the bigger the inertia, and before you know it there a are tons of features in their that are far less valuable in the new situation. Cutting away perfectly good features is always painful but at some point you end up with the toolbars of Microsoft Word. Nice features, but complete overkill for the average user.

4.) The cause and effect trap

When people are faced with an issue they tend to focus on fixing the issue as it manifests itself. It's hard for our brain to think in problems, it tries to think in solutions. There is an excellent blog post here that provides a powerful method to overcome this phenomena by asking five times "why".

  • "We need the system to automatically export account details at the end of the day."
  • "Why?"
  • "So we can enter the records into the finance system"
  • "So it sounds like the real problem is getting the data into the finance system, not exporting it. Exporting just complicates the issue. Let's implement a data feed that automatically feeds the data to the finance system"

The hard job is to continuously keep evaluating your features, and remove those who are no longer valuable. It may seem like your throwing away good code, but ultimately it is not the largest product that survives, but the one that is able to adapt fast enough to the changing market. (Freely after Darwin)


Categories: Companies

Four Tips for Managing Performance in Agile Teams

Johanna Rothman - Tue, 03/03/2015 - 14:32

I’ve been talking with clients recently about their managers’ and HR’s transition to agile. I hear this common question: “How do we manage performance of the people on our agile teams?”

  1. Reframe “manage performance” to “career development.” People on agile teams don’t need a manager to manage their performance. If they are retrospecting at reasonable intervals, they will inspect-and-adapt to work better together. Well, they will if managers don’t interfere with their work by creating experts or moving people off project teams.
  2. The manager creates a trusting relationship with each person on the team. That means having a one-on-one weekly or bi-weekly with each person. At the one-on-one, the manager provides tips for feedback and offers coaching.  (If the person needs it or wants it from the manager.) The person might want to know where else he or she can receive coaching. The manager removes obstacles if the person has them. They discuss career development.
  3. When managers discuss career development, each person needs to see an accurate view of the value they bring to the organization. That means each person has to know how to give and receive feedback. They each have to know how to ask for and accept coaching. The manager provides meta-feedback and meta-coaching.
  4. If you, as a manager, meet with each person at least once every two weeks, no problem is a problem for too long. The people in the team have another person to discuss issues with. The manager sees the system and can change it to help the people on the team.

Now, what does this mean for raises?

I like to separate the raise from the feedback. People need feedback all the time, not just once a year. That’s why I like weekly or biweekly one-on-ones. Feedback isn’t just from the manager to the employee; it’s two-way feedback. If people have trouble working in the current environment, the managers might have a better chance to change it than an employee who is not a manager.

What about merit raises? This is tricky. So many managers and HR people continue to think one person is a star. No, on well-functioning agile teams, the team is the star—not individuals. You have options:

  • Make sure you pay each person at parity. This might not be trivial. You need expertise criteria for each job level.
  • When it comes to merit raises, provide a pot of money for the team and ask them to distribute it.
  • Distribute the merit money to each person equally. Explain that you are doing this, so people provide feedback to each other.
  • Here’s something radical: When people think they are ready for a raise or another level, have a discussion with the team. Let the team vote on it.

Managers have to not get in the way when it comes to “performance management.” The people on the team are adult humans. They somehow muddle through the rest of their lives, successfully providing and receiving feedback. They know the worth of things outside work. It’s just inside work that we keep salary secret.

It might not fit for you to have open-book salaries. On the other hand, how much do your managers and HR do that interferes with a team? You have to be careful about this.

If you reward individuals and ask people to work together as a team, how long do you think they will work together as a team? I don’t know the answer to that question.

Long ago, my managers asked me to be a “team player.”  One guy got a huge raise—and I didn’t, although I had saved his tush several times—I stopped working as a “team” member. I got my big raise the following year. (Year!) This incongruent approach is why people leave organizations—when the stated way “we work here” is not congruent with the stated goals: agile and self-organizing teams.

What do you want? Managers and HR to manage people? Or, to lead people using servant leadership, and let the teams solve their problems and manage their own performance?

If teams don’t know how to improve, that’s one thing. But, I bet your teams do know how to improve. You don’t have to manage their performance. You need to create an environment in which people can do their best work—that’s the manager’s job and the secret to “managing performance.”

Related posts:


Categories: Blogs

3 Thinking Tools for Minimizing Dependencies Between Products

Leading Agile - Mike Cottmeyer - Tue, 03/03/2015 - 11:00

In my post about how to form teams, I talk about products… not in their monolithic, holistic state… but as a subsystem within a larger integrated solutions architecture. In other words, big products are just series of small products that work together in an integrated fashion. Each of these smaller products have a backlog, a team, and the team can produce a working, tested, increment of the product on regular intervals… you get the idea.

There are tons of reasons that make this approach a great way to build software. Code ownership is less complex. Branching strategies simplify. We have a much smaller group of people interacting with the code base and business logic, etc. The downside of this approach is that you’ll probably have to coordinate requirements dependencies between teams and you’ll often introduce sequencing dependencies between sub-systems.

We’ve established that dependencies are evil, so let’s talk about a few strategies for breaking them or at least minimizing their impact:

1. To fully break dependencies between products and shared components, products can only commit to features built on capabilities already present in the shared component. Products can request new capabilities from their component teams, but those requests go into the queue and get done when they get done. It’s as if the component team was a separate company having to balance the needs of multiple customers to provide the most value to as many people as possible. The product team can request new capabilities, but they cannot mandate them or set a date.

2. To minimize dependencies between products and shared components, products can only commit to capabilities that are on the near term roadmap of the component team. In this case, if the component team is stable and has a known velocity… and they can reliably size your request… and let you know where you fit into their backlog… it might be safe to bet on the fact that nothing will change and you can get your capability added in the sprint or release that the component team has planned. This is only safe a sprint or two or maybe a release out.

3. To manage dependencies between products and shared components, products inject capabilities into the component teams backlog and force a dependency. This is the most risky of all strategies, but could possibly be necessary in some circumstances. In this case, each team better have a stable backlog and a known velocity and be able to make and meet a commitment with a pretty high level of confidence. If this is an exception to the rule, and only used as a last resort, you might be able to get away with this occasionally. Again, this is the least desirable approach.

So in short:

1. Never commit to a feature the depends on a component capability that does not exist
2. Sometimes commit to a component capability on the near term roadmap
3. Rarely commit to a component capability with a hard date driven dependency.

Let me know if you have any questions or comments. I think this is going to be a challenging concept for many folks. I’m interested in your thoughts.

The post 3 Thinking Tools for Minimizing Dependencies Between Products appeared first on LeadingAgile.

Categories: Blogs

Book Review: Waltzing with Bears - Tue, 03/03/2015 - 10:54

I read this book very early in my career, and I thought it would be useful to read it again as a refresher to risk management. Waltzing with Bears is a book that focuses on the identification and management of risks within the software industry. It’s filled with a number of stories answering the question, “Why should we care about risk?” as well providing a number of strategies and tools for handling risk.

Waltzing with Bears

Although a lot of the advice is still applicable today, I think it is true that some of the recommendations are commonplace today. They recommend, for instance, an incremental delivery approach to software (Hello agile software development!) without a specific reference to a methodology as a way of mitigating risk.

They also present the idea of estimate (un)certainty and using the idea to make better commitments to others. They also warn against default behaviour that is still rife in our industry: e.g. making a commitment to others based on an optimistic estimate hoping for a series of breaks when it is clearly high risk, which later leads on to the project death march, or a huge loss of quality.

Reading the book the second time around, I picked up a few other interesting models I don’t remember so clearly from the first time around including the use of probability profiles (a graph that shows the shape of our estimates and the uncertainties) to understand when and where to give estimated dates. There’s a useful section around risk-storming for people who have never been to a risk brainstorming session, but that wasn’t particularly new for me. Another one is the use of the Monte Carlo simulation for calculating the impact of risks. After reading that section however, I feel like I still don’t fully understand it and I would need to practice applying it for me to fully understand how that works.

Although the examples used in the book are relatively old now, there are still powerful stories about how people failed to manage risk, what they could have done instead and what the consequences were (e.g. Dallas Airport Baggage system!) I also like their practical experience shared when they talk about the cultural side of risk (e.g. how transparent or open and organisation is) and when it’s dangerous to share your view of risk. This sort of advice is often missed from books where the authors provide a very one-sided dogmatic approach without the consideration of contexts.

Overall this is an easily digestible book that introduces the idea and the importance of managing risk together with tools to help you achieve it, all set in the software industry context.

Categories: Blogs

Agile Ci2i

Growing Agile - Tue, 03/03/2015 - 09:00
Last month (9 – 11 February 2015) we attended the Scrum Coach Retreat in South Africa. Karen found herself in a group that was focussed on learning to coach management through success and failure stories from other coaches. They created Agile Ci2i.

One of the common themes at the coach retreat was how to get senior managers and C-level executives to understand the mindset, culture and environment that is required for agile to succeed. As coaches we have the experience to see when a company culture will make agile easy to adopt, or vice versa. However many coaches struggle to coach senior leaders to help them understand this point of view.

We decided that the best approach to the problem was to pool our knowledge and stories of similar situations in trying to get management to adopt a new mindset. We wanted to create a platform that could live far beyond the retreat and get more people contributing. The more contributors the greater the knowledge base. So we created Agile Ci2i (pronounced see eye to eye). It’s a wordpress site, and anyone in the agile community can apply to get author rights. Just email us. Currently we have 5 scenarios, with more planned in the future.

Agile Ci2i

Read the content we have so far.
Add some of your own ideas.
And help us spread the word.

Categories: Companies

Product Owner Survival Camp, Vienna, Austria, March 19-20 2015

Scrum Expert - Tue, 03/03/2015 - 08:55
Product Owner Survival Camp in Vienna is a two days of practical workshops of Product Owner. Four distinguished experts will teach you how to apply the right techniques at the right time to get the full benefits of Agile software delivery. In the agenda of Product Owner Survival Camp, Vienna you can find the following workshops ” Discover to Deliver” with Ellen Gottesdiener, “Impact Mapping” with Gojko Adzic, “The Anatomy of a User Story” with David Evans, “Build/Measure/Learn with Story Maps” with Christian Hassa. Web site: Location for the Product Owner Survival ...
Categories: Communities

The Evolution of Teams

Leading Answers - Mike Griffiths - Tue, 03/03/2015 - 07:19
My other workshop submission for the Agile 2015 Conference is titled “The Evolution of Teams” and examines one team that stopped doing the traditional agile practices is more agile than ever. Agile practices such as daily stand up meetings, sprint... Mike Griffiths
Categories: Blogs

Agile For All adds three new members to the team

Agile For All - Bob Hartman - Mon, 03/02/2015 - 20:30

Peter playing his trumpet!

In case you missed the press release, Peter Green, Adobe Systems Agile Transformation Leader, will join our Agile For All team on March 16th. I am personally excited about Peter’s amazing contributions to the Agile community and his enterprise level experience. I’m also excited to say that Peter isn’t the only one joining the team! See below for more details on all of the exciting news.

For those of you that don’t know him, Peter led a grass roots Agile transformation at Adobe from 2005 to 2015, starting with his own team, Adobe Audition. His influence includes the teams behind such software flagships as Photoshop, Acrobat, Flash, Dreamweaver and Premiere Pro, as well as dozens of internal IT and platform technology teams and groups like marketing and globalization. Peter has always shared with the rest of the Certified Scrum Trainer community the things that worked, and those that didn’t work for him at Adobe. I’ve always been impressed by his openness.

His work was a major factor enabling Adobe product teams to make the critical business transition from perpetual desktop products to the subscription-based service, Creative Cloud. His hands-on Scrum and Agile training and coaching helped lay the groundwork to shift teams from two-year product cycles to frequent delivery of high-quality software and services. It is quite rare for a large, established software company like Adobe to successfully transition to the cloud. As Patrick Seitz wrote in Investor’s Business Daily, “In terms of building up its cloud subscriber base, Adobe is hitting it out of the ballpark.”

More recently, Peter collaborated with Adobe’s VP of Creativity Mark Randall to develop the now open-source Adobe KickBox program, described in Fast Company here and more recently on here.

Regarding the transition to Agile For All, Peter said, “There were two key factors for me in deciding to leave Adobe and join Agile For All. First of all, I’ve been a big fan of the Agile For All team Bob Hartman, Richard Lawrence and Peter Saddington for a long time. They constantly strive to improve their own approaches to training and coaching, and to openly share what they learn with the broader agile community. Secondly, I’ve been really impressed with the companies that they work with. These companies are trying lots of cool new approaches to running a business that are closely aligned with my own personal perspective — trust people, and let your approach stem from that trust.”

After deciding to leave Adobe, Peter obviously had choices for what he could do moving forward. In our conversations with him he made it clear that going with Agile For All felt right to him because he shares our desire to change the status quo for ourselves and for our clients. He brings a tremendous amount of knowledge about effectively scaling organizations of all sizes, and is well known as an Agile thought leader — helping the rest of the Agile world learn from his experiences on a regular basis through his writings and conference presentations. In fact, you can see him at the Mile High Agile 2015 conference here in Denver on April 3, 2015.

In addition to Peter Green, two other noted Agile thought leaders are joining the Agile For All team: Jake Calabrese, formerly of Agility Street, and Henry Dittmer, formerly of Swift Ascent.


Jake Calabrese

You can see Jake’s bio on our site here so I won’t go into those details. Instead, let me tell you why I’m excited Jake is joining the team. I’ve known Jake since 2007 and have been more impressed with him as I’ve learned more about him over time. He has reinvented himself at least 10 times since 2007, and each change has been positive. He loves learning new things and integrating them into what he does. He is passionate about coaching people to be the best they can be, and that’s what we try to do every single time we work with a client.


Henry Dittmer

Like Jake, Henry’s bio is here. I’ve known Henry since giving a class to his group from Avaya in 2007 and have always loved his desire to help executives understand the Agile mindset he himself had to learn over many years. His passion for communicating with each individual in a way compatible with the mindset of that person is amazing. I love watching him work. I learn something every time we are at a client together.

Why should you care about this announcement? Because by adding these three amazingly talented people, Agile For All now has more depth and breadth of experience to help clients reach their potential. Peter, Jake and Henry take vast amounts of experience from working in real companies as well as working as trainers and coaches, and they bring that knowledge to each engagement. Their knowledge and experience overlaps with the core of what Agile For All does, but also expands beyond that core in ways that help us engage a wider variety of clients. For example, Jake has done a lot of work around use of Agile outside of software development and is a speaker at the Agile and Beyond 2015 conference. Henry is well versed in systems thinking as applied to organizations and the flow of value creation, especially from the management and executive level. Peter brings a lot of experience around scaling Agile implementations within large companies and will be helping us create a course for the new Scrum Alliance Scaling Added Qualification. We could have done each of these things prior to Peter, Jake and Henry joining us, but with their added expertise and experience we can reach new heights in these areas.

I am personally excited about these great new additions to our team. Agile For All continues to exceed every expectation I had when I founded the company back in 2008. I’m blessed to be working with such awesome people!

Leave a comment to say “Hi” to Peter, Jake and Henry (and maybe share a story about them!). Also be sure to let us know how we can help you on your quest toward Making Agile a Reality® for you and your organization!

The post Agile For All adds three new members to the team appeared first on Agile For All.

Categories: Blogs

Knowledge Sharing

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