Skip to content


Updated: The Best Agile Practices to Implement Now

Learn more about our Scrum and Agile training sessions on

This article which lists three high-ROI practices has been updated with new images and a few other minor fixes:

The Best Agile Practices to Implement Now

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


Scrum Log Jeff Sutherland - Fri, 03/06/2015 - 02:36

Muda, or wasted effort, is one of the three types of waste outlined by Taiichi Ohno in his seminal book, The Toyota Production System. (See the slide below for a breakdown of all three forms of Waste.) Ohno’s work captured the essence of what is called Lean manufacturing in the West. He wrote that the first step in applying the Toyota production system is a simple idea: identify and eliminate waste. Rather than inventing a new process, first eliminate the waste in the existing system. There will be a dramatic improvement in productivity and, more importantly, the process will fundamentally change. 

Removing waste will lay your process bare. Now you can now make explicit changes to it and then inspect and adapt accordingly. Changing your process before eliminating waste is a bit like rearranging the deck chairs on the Titanic. In Scrum, we often treat waste as  Impediments.  It is important to identify, track and remove it.

Ohno broke Muda down into 7 categories. They are broken down in the tabs below. 


waste.066 waste.066 waste.067 waste.067

stock-footage-video-footage-of-a-food-over-production-of-pumpkinsMaking more of something than will actually sell is a form of waste. In farming this is like growing more product than the market will consume. That extra production is just pure waste. Money and resources are tied up in product, not helping to add value to the organization.

In new product development this waste happens when teams don’t follow the 80/20 Rule. (The idea that 80% of a project’s value is in 20% of its features.) It is the Product Owner’s responsibility to correctly Assign Business Value to backlog items so the team does not work on features that have relatively low value. A strong Definition of Done will also help prevent team members from doing more work than is needed to produce a valuable feature.  Often organizations fall in love with process itself and forget about the product. Over-detailed documentation, unnecessary management overhead, and excessive reporting are some common examples of process waste. Organizations have legal and functional reasons for requiring process and documentation but it is important that these activities help create business value and aren't simply outdated or misguided. Every step a worker has to take to move a product from one machine to another is waste. There’s going to be some, but it should be ruthlessly minimized.

A famous example was when Toyota took over the NUMMI automotive plant from GM. One gigantic multi-ton machine was fifty or so feet out of its optimum position. GM just worked around it. Toyota got every employee in the plant to lift the machine with only human muscle and move it those fifty feet. Stopping production for the couple of hours paid off by removing those minutes of waste inherent in the previous layout.handoff

Transportation waste isn't limited to a production line. In an office environment, transportation waste often takes the form of poorly coordinated  hand-offs between team members. Scrum Inc. Multi-Tasking

This is often associated with context switching, or what most people refer to as Multi-Tasking. Research shows that context switching creates incredible amounts of waste as the brain sets aside the knowledge needed to perform one task and accesses what it needs to perform the next. Choose a job, complete it and then move on. The slide above has a break down of how much waste is created switching between jobs. standing-in-lineOn a production line, if a machine is waiting for another machine to finish its job, each minute of waiting is waste. In Scrum, if a Team isn’t well cross-trained, a lot of time can be wasted waiting on a Team member to complete a job no one else can do.

The key to eliminating waiting is minimizing dependencies on expertise, information or materials. Poor communication can create delays if a Team member has to wait on a critical piece of information. In manufacturing, if a critical piece of hardware hasn’t been delivered, the entire enterprise might have to wait until it arrives. Software developers are familiar with this form of Muda. If a Team isn’t creating daily clean code, a lot of time can be wasted going back to fix bugs. We cannot stress strongly enough the importance of addressing bugs quickly and on the same day they are discovered, and if you’re doing continuous integration, on the same day they are created. Research has shown that fixing a bug a week later can add a factor of 24 to the time it takes to fix a bug. In other words, fix a bug today, and it will take an hour, fix it in a week it will take three 8 hour days.

Regardless of the industry, going back to correct mistakes creates waste. Errors can be limited by building quality control into the development process so that issues are discovered and corrected at the point of origin. In Scrum, the speed of development is driven by the quality of the work. Do it right the first time and eliminate the waste of re-work in the future.  In Scrum this is called Work in Process, often shorthanded as WIP. The waste occurs when a team works too many items simultaneously. This slows the team down an prevents them from moving any one item to done quickly.


The post Muda appeared first on Scrum Inc.

Categories: Blogs

NeuroAgile Quick Links #11

Notes from a Tool User - Mark Levison - Thu, 03/05/2015 - 22:59
A collection of links to interesting research from the world of neuroscience and behavioural psychology that can be applied (or not) to Agile/Scrum Teams.
Categories: Blogs

A Perspective on SAFe and Scrum from Outsourcing in Latin America

Agile Product Owner - Thu, 03/05/2015 - 20:36

Bianca Wright, Managing Editor for NearShore Americas – an on-line trade journal focusing  in IT outsourcing in Latin America- just put up an interesting post on “SAFe vs. Scrum”. And as she notes that it isn’t really an either/or, I thought it would add to the dialogue, so I’m posting it here.

 The Right Kind of Agile: “Global Delivery and Agile Development Must Work in Harmony”.

I’ll file this in the Fun with Methods Category.

Categories: Blogs

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

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

HICSS 2016 – Call for Papers

Scrum Log Jeff Sutherland - Wed, 03/04/2015 - 21:28

HICSS is one of the top conferences in paper citation index rankings. This means papers will be seen and used by researchers worldwide more than papers from other conferences. All HICSS papers are published in the IEEE Digital Library and are FREE to download, so accepted papers are accessible to everyone for the rest of time. No other conference gives you the same distribution of your ideas. Plus it is held Kauai in January. Write, publish, vacation!

For more details visit their web site at

Call for Papers: Agile/Lean at HICSS (Kauai, January 5-8, 2016)

We invite you to submit manuscripts for the Agile and Lean: Organizations, Products and Development mini-track, to be held at HICSS-49 on January 5–8, 2015 at Kauai, Hawaii. We welcome papers from academics, practitioners and (even better) academic-practitioner collaborators. Co-chairs are Daniel R Greening (Senex Rex), John Tripp (Baylor University) and Jeff Sutherland (Scrum, Inc.).

HICSS logo The Hawaii International Conference on System Sciences(HICSS) provides a great mix of academics, industrialists and consultants studying many applications and aspects of system science. Now in its 49th year, HICSS is one of the longest-standing continuously running scientific conferences. HICSS is an IEEE Computer Society sponsored conference. HICSS papers are in the top 2% of conference papers downloaded from IEEE. Topics

We seek research papers and experience reports that explore agile development, lean product management and agile/lean organizations. What evidence-based guidance can we provide to product leaders, managers and developers to help motivate, create and sustain better agile/lean behaviors and more profitable outcomes? How can we incorporate product design, architecture, engineering, risk reduction, budgeting and offshoring into agile/lean while preserving experimentation and adaptation? What common behaviors do we see in agile (including Scrum, Kanban, Extreme Programming/XP, etc.) teams and lean product management (including Lean Startup, Customer Development, etc.) and how do those behaviors affect outcomes? How do organizations and cultures restructure to support these philosophies and when they do not restructure, what happens? Which metrics help enterprises, teams and individuals adapt and improve?

Deadlines March 15, 2015. Submission system available

Follow author instructions found on select “Software Technology” track and “Agile and Lean” mini-track.

May 15, 2015. Early review (optional) deadline

Abstract and manuscript submissions received before May 15, 2015 will receive early guidance to improve the likelihood of acceptance.

June 15, 2015. Submission deadline

Submit full manuscripts for review. Review is double blind; your submission must omit author names, credentials and affiliation. Follow author instructions found on select “Software Technology” track and “Agile and Lean” mini-track.


Agile product development rhythmically experiments with development behavior to improve production. Agile is most often applied to software development, and we expect some papers in this mini-track to discuss software organizations and software engineering practices. However, we also welcome papers that describe other types of organizational “production”, such as business intelligence, management initiatives, manufacturing, marketing, sales and finance.

Lean product management experiments with markets to improve revenue, continually seeks to reduce waste, including waste due to producing unprofitable products (recently popularized as “Lean Startup” or “Lean Entrepreneurship”). Characteristics include: set-based design, A-B testing, unmoderated user-experience testing, direct market experimentation, customer validation and pivoting. Advocates claim lean product management produces greater market satisfaction and customer engagement, earlier discovery of hidden market opportunities, higher revenues and more efficient use of development staff.

Experimentation characterizes both approaches: they identify leading indicators of progress (velocity, reach, engagement, loyalty, revenue, etc.), consider changes to process or product, construct hypotheses, and incorporate feedback loops to confirm or invalidate the hypotheses, perform production or market experiments, and rapidly adapt to discoveries.

These approaches claim superiority in new product development over traditional approaches (such as “waterfall management”) that fail to test development and market assumptions in long-range plans.

Agile and lean approaches challenge organizations large and small. People typically conflate small failures (learning) with large failures (organizational threats), assume that innovation means taking long-range untested risk, and establish and protect budgets with many baked-in production and market assumptions. These cultural realities interfere with agility and real innovation.

As a result, companies often invest enormous amounts of money in incomplete or abandoned agile transformations. What can organizations do to improve agile uptake? How do we know that the organization is improving? How can organizations diagnose problems without motivating gaming? What types of people are more likely to thrive in agile and lean organizations, and what roles should they take? What hiring practices result in better candidates? What training programs produce better results? What coaching structures work? How do we measure these activities?

Possible topics for the minitrack include but are not limited to:
  • Empirical outcome comparisons in industrial settings: agile and non-agile, remote and collocated, impact of different agile methods, etc.
  • New frontiers in agile management – going beyond software development
  • Forecasting, risk reduction, planning
  • Agile organizations as rhythmic and recursive experimention
  • Exploring the fit between agile organizations and their environmental context.
  • Agile and Lean requirements engineering, dependency management and risk management
  • Conflict in agile organizations and agile development teams: what cultures work and don’t work?
  • What cultures and leadership characteristics lead to sustained agility?
  • Evolution of agile organizations
  • Case studies on agile management and experimentation, in atypical situations
  • New approaches to teams and teaming
  • Impact of tool use on agile management
  • New approaches to teaching and coaching agile organizations
  • Lessons learned in agile management
  • How do agile management and traditional management complement or conflict?

We’re looking forward to seeing your submission, and seeing you at HICSS January 5-8, 2016 in Kauai!

The post HICSS 2016 – Call for Papers appeared first on Scrum Inc.

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

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

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

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

Clean Tests: Isolating the Database

Jimmy Bogard - Mon, 03/02/2015 - 19:35

Other posts in this series:

Isolating the database can be pretty difficult to do, but I’ve settled on a general approach that allows me to ensure my tests are built from a consistent starting point. I prefer a consistent starting point over something like rolled back transactions, since a rolled back transaction assumes that the database is in a consistent state to begin with.

I’m going to use my tool Respawn to build a reliable starting point in my tests, and integrate it into my tests. In my last post, I walked through creating a common fixture in which my tests use to build internal state. I’m going to extend that fixture to also include my Respawn project:

public class SlowTestFixture
    private static IContainer Root = IoC.BuildCompositionRoot();
    private static Checkpoint Checkpoint = new Checkpoint
        TablesToIgnore = new[]
        SchemasToExclude = new[]

    public SlowTestFixture()
        Container = Root.CreateChildContainer();

Since my SlowTestFixture is used in both styles of organization (fixture per test class/test method), my database will either get reset before my test class is constructed, or before each test method. My tests start with a clean slate, and I never have to worry about my tests failing because of inconsistent state again. The one downside I have is that my tests can’t be run in parallel at this point, but that’s a small price to pay.

That’s pretty much all there is – because I’ve created a common fixture class, it’s easy to add more behavior as necessary. In the next post, I’ll bring all these concepts together with a couple of complete examples.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

A Systems Approach to Leadership

TV Agile - Mon, 03/02/2015 - 19:32
Many organizational change initiatives fail due to lackluster leadership support. This should not surprise us as we often find that just below the surface nothing has changed. We should not expect organizations to transform if we don’t design an ecosystem that allows emergence and growth to thrive. The future of leadership lies in the ability […]
Categories: Blogs