Happy Holidays!

December 24, 2013

It's that time of year, and I'm taking a couple of weeks off from regular blogging. I wish everyone all the best, and I look forward to an exciting 2014!

More Communication, Less Documentation

December 15, 2013

Document-centric processes have taken hold in many organizations, and they are now drowning in that documentation. As companies want to understand how to get faster and be more innovative, one key is to document just enough and have conversations that drive towards more innovative, productive results. As we’ll see, agile development provides a framework for making this happen.

The Product Backlog as Communications Hub
With agile development using Scrum (the most popular agile framework in use today), we overlap product definition and delivery activities by incorporating a coordinating mechanism known as a Product Backlog. Conceptually, the Product Backlog fills that previously blank overlap area between product definition and delivery that I included in my Cone of Uncertainty diagram in my last post. Figure 3.5 shows the Product Backlog occupying this area:
Figure 3.5
As you may thinking based on the previous material, this model doesn’t fit agile development because the Cone of Uncertainty is created by plotting two points that represent the variability present at a given point in time, which are based on traditional project phases of project inception, requirements elicitation, design, develop and test (plotted from left to right on the diagram). And you are quite correct.

This model is useful to illustrate that with agile development, we are striving to keep the costs down in comparison to traditional approaches. The left-hand side of the cone – the Define area – where the cone is the widest and where we have the greatest variability and uncertainty, so we want to avoid overinvesting this area by creating large batches of detailed requirements along with plans and schedules that are cast in concrete based on those requirements. This area is where a great deal of waste originates, as any planning that we are doing is relying on information that most likely will change when we get to the brass tacks of actual implementation.

Agile Development: Learning While Working

December 3, 2013

The amount of variability that we will encounter with software projects depends upon the individual context of each project. In situations where there is very low variability in both the business and technical domains, an agile approach may not appear advantageous since more is known than unknown, but these situations are not common. (However, an agile approach can still be beneficial through its support of things like continuous improvement, low overhead, visibility and transparency.)

Even if we believe that we are in a low-variability scenario, it more likely that we are: a) underestimating the amount of variability involved and/or, b) overlooking something concerning the entire customer value stream where we are a part of a larger process.

Let’s consider the latter point first using an example from my previous post, where I talked about the implementation of home or auto insurance in our software (for a company where I previously worked). I stated that this was all about transforming a previously defined and approved insurance product definition into our software using tools that we provided. Using this perspective, there was low technical and business variability.

But this is also a limited view of the entire value stream from a customer’s perspective. If we expand our thinking a little, it becomes clear that there is an opportunity to combine the actual product definition for regulatory approval purposes and its implementation in our software. In other words, if we actively participated in the upstream product definition activities, we could make things more efficient and effective for the customer.

Moving back to the first point about underestimating variability, the historical track record of software projects delivering on time, on budget, with expected features speaks for itself. As covered in Chapter One, it doesn’t happen often, and odds are that we will contend with enough variability to throw us off our pre-planned track. This doesn’t make variability the enemy, just something we need to acknowledge and manage.

When Should We Utilize an Agile Approach?

November 25, 2013

Our goal with planning software projects is predictability. But as we’ve proven with traditional approaches, our age-old enemy – variability – inevitably creeps into the equation to wreak havoc with our plans. This isn’t a planning failure; it’s a failure to assume that we can plan with certainty up front.

The Cone of Uncertainty (McConnell, 1998) is an excellent visual model that captures this dynamic. It plots the range of variability encountered with software projects as they progress through time. Figure 3-1 depicts the general shape of the Cone of Uncertainty, minus the actual data points used to create the cone.


Figure 3-1

The Benefits of Agile Change

November 15, 2013

If you are going to adopt agile, you are in for a change. But why change? What are the benefits that you should expect from agile development? In other words, what is in it for you?

In the latest VersionOne State of Agile Survey, ninety percent of the respondents reported improvement in managing changing priorities by implementing agile. This is not a big surprise since agile is often billed as being able to respond to changing requirements.

In that same survey, eighty five percent of the respondents reported an increase in productivity. Since agile development is a lightweight approach to software development, we should expect an improvement. Less overhead – while retaining the necessary framework for coordinating and managing work – certainly contributes to improving productivity.

Couple this with a few other ingredients like greater collaboration, combining of conventional tasks to reduce formal handoffs and practices designed to increase feedback and produce working software in short cycles with quality, and we have the critical elements in place that lead to greater productivity.

Here’s a reported benefit from the VersionOne survey that might make you think: Eighty-four percent of the respondents reported an improvement in project visibility.

Despite all of our planning, reporting and tracking with non-agile approaches, agile still manages to improve project visibility. What is the difference?

The Breadth of Agile

November 7, 2013

As I thought about the model in Figure 2-1 from my last post, I adapted it to make something else more explicit when talking about agile development and setting agile expectations. This speaks to the breadth of agile as opposed to its depth.

I observed that the bottom three layers are more timeless than the top layer. Specific frameworks are implementations of agile; practices and techniques may change over time while the values, principles, and characteristics are qualities that will stand the test of time. So I lopped the top layer off. This provides us with a deep, rich set of agile qualities that comprise a common core.

And while these agile qualities comprise a common core, they will be realized in different ways at a personal, team and organizational level. And these elements are all interrelated, as Figure 2-2 depicts:


Figure 2-2

Now we have a little more to explore as we consider the previous learning example. Agile is now being implemented broadly, giving us depth and breadth. Let’s start with personal agility.

What is Agile Development?

October 31, 2013

Here are some of the responses that I’ve heard over the years:
  • It’s a mindset or a philosophy.
  • It is the values and principles of the Agile Manifesto.
  • It is a framework rather than a methodology.
  • It is a way to get more features out the door quicker than ever before.
  • It is something that the development teams do.
  • Agile development is anarchy! (I haven’t heard this one lately).
Perhaps you have a variation of one of these in mind, or even another, very different definition. Perhaps you’ve heard of technical practices like Test-Driven Development (TDD). What does all of this mean?

One of the challenges with agile development is that it defies being meaningful y described in a sentence or two. I’ve tried, but I never liked the results. I’ve also heard people criticize agile development because it can’t be defined succinctly.

Our Beliefs Box Us In with Software Projects

October 24, 2013

“Doctor, every time that I do this, it hurts! What can I do?”

“Well, don’t do that anymore!”
– Old Joke
Why do smart people continue to do things that hurt when it comes to software projects? Because we’re human; and as humans who have been actively and continually working at improving our software development efforts we have come to believe certain things. Those beliefs are in turn reflected in what we value. And because we value certain things, these values are incorporated into the approaches and practices that we subscribe to as a means of achieving success.

If we believe software projects are predictable, for example, then we value the process of planning, which leads us to implement an approach and practices that support gathering information and planning in detail up front. (Mezick, 2012)

This is also why it becomes a challenge to change. As humans we want a balance between what we believe and value and our behaviors and actions. If there are inconsistencies, we will find ways to eliminate those inconsistencies. (Keller, 2011)

Software Projects Never Go According to Plan

October 17, 2013

My previous post walked through a common software development scenario where everything appeared to be well-planned at the beginning of the project, but as work progressed, the project came off the rails. This is a common scenario because software projects invariably fail to go as planned. Figure 1-2 depicts how we envisioned the process:


Figure 1-2

Our expectation was that we could define our requirements fully up front and send them through our product development pipeline where those requirements were augmented with designs, transformed into working software, validated and ultimately delivered using a crisp, well-defined sequence of steps – all executed according to plan. However, our experience proved that things don’t work this neatly in actual practice.

One problem was that as work got into that pipeline it got bigger than what was originally planned, clogging the pipe in some cases. Our initial estimates were off because we lacked critical information about the users’ true needs. We uncovered those needs as we implemented features. This meant that our initial certainty about the requirements and the confidence in our planning based on those requirements was actually misleading.

Agile and The Need For Change

October 9, 2013

This post contains draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran



Before we talk about what agile development is, why are you considering it? Is it because agile development is the new, cool thing to do? If the cool kids are all doing it, we won’t look good (cool) because we aren’t doing ourselves, right?

As agile development has gained momentum in recent years there seems to be more comments about internal pressure “from above” to adopt agile in organizations, despite limited knowledge about just what being agile is all about. If this is where you are, this guide will help you understand what agile can do for you.

Perhaps you already have some very specific reasons for adopting agile development. In other words, you are dissatisfied with the status quo in one or more ways. In that case, this guide can confirm that your own dissatisfaction has merit and that agile can indeed help your situation.

Agile Expectations: Introduction

October 3, 2013

This post contains draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran

The inspiration for this guide comes from my own agile journey that began with one development team in 2005, quickly migrating to all of our teams. In fact, the title of this guide began life as a document I started with our management team early on during our agile adoption.

In 2005, I was working for a software company as the Director of Software Development. We had just completed development of a large, complex product that no one in our organization felt was a rewarding, satisfying experience. The only satisfaction came in claiming victory; claiming being the key word.

We had a lot of fixing up to do. The schedule pressure had been enormous, the requirements continually shifted throughout the development effort and sections of the code – despite this being a 1.0 release – really needed re-factoring. The pressure to cram too many features into a first release had led to inevitable shortcuts by tired, overworked, desperate developers.

It was this team that approached me about trying agile development. I’ll confess that I didn’t know that much about agile development at this point in time. I had heard of it and read a little about it, and I had even attempted to learn more a year or so prior to this from some XP (eXtreme Programming) developers that I met at a development conference.

An Agile Project for Me and a Sneak Preview for You

October 2, 2013

I have ideas for a couple of books on agile. For the past four years I’ve been writing about agile on this blog (and other blogs here and there) along with publishing some articles on the side, so this seems like a good next step. I’ve actually pushed off suggestions in the past to write a book, but right now, the timing feels right.

I’ve got notes and thoughts on the direction I want to take, but time is a precious commodity for me as it is for all of us… So I want to write my first book while I continue with this blog and earn a living. (My blog does not earn me living!) The simplest and most direct thing to do is to a) write the shortest book I have in mind first, and b) draft my book in public, using this blog.

The book I have in mind is something that I can hopefully self-publish and make available fairly quickly. The goal for this book is to answer the question: What is agile and what should you expect from agile?

My tentative title for this book is: Agile Expectations: What to Expect from Agile Development, and Why

I’ll make another post tomorrow, starting off with what will be the Introduction to the book. I will organize the material in chapter format on this blog as I’m writing it. This will be the sneak peak for you. Once I’m complete, my intent is to package the material up and publish it – provided that I’m satisfied that the content is indeed worthy of publishing.

As always, any feedback on what is working and what I need to improve is always welcome!

Why You Should Adopt Agile

September 25, 2013

Are you on the fence about adopting agile? If so, what is holding you back?

Agile development is all about delivering the greatest value in the shortest time possible, using the least amount of effort. This does not equate to being simplistic; it’s about using the most direct approach to accomplish what is needed. For those who are considering adopting agile (and for those who need to persuade others), here are some points to consider.

Iterating is NOT Just a Re-Work Strategy

September 18, 2013

Not with agile development, anyway…

When iterating is taken at face value without further discussion and clarification, the concept can create a misunderstanding about what we’re striving for with agile development. Here are a couple of negative connotations typically associated with iterating:
“We’re re-taking ground that we have already covered.”

“We didn’t‘do our homework up front.”
This can lead to that inevitable judgment:
“This agile stuff is crap. We’ll never get anything done by continually re-working everything.”
In the first place, if you are re-working everything, something is fundamentally wrong that any process alone can’t fix. It’s a signal that you aren’t aligned with what your customer wants. In fact, you don’t even have a basic understanding of what your customer really needs.

What It Means to Be Adaptable

September 11, 2013

“Responding to change over following a plan” is one of the four values of the Agile Manifesto. Is your first reaction to think about changing requirements? This is often the general perception of what adapting means in an agile context, particularly when we refer to one of the principles of the Agile Manifesto:
“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”
We do need some flexibility in our thinking and approach so that we can adapt to new or changing business requirements. We can’t have the mindset that everything is cast in stone and unchanging because software development is a product development exercise where learning and discovery will take place.

Order in the Backlog!

September 4, 2013

Ah, the English language! It is rich, yet full of little nuances that can create difficulties. For example, what is the difference between a prioritized Product Backlog and an ordered Product Backlog?

For those who may have overlooked it, the 2011 Scrum Guide changed from referring to the Product Backlog as being prioritized to it being ordered. And since this wording was retained in the 2013 version of the Scrum Guide, just what is an ordered backlog, and how is it different from being prioritized?

Let’s start with prioritization, which can be a challenging thing to do because I’ve come across managers (stakeholders) who desire multiple “number one” priorities. Yes, this is a case of not prioritizing at all. Enough said on that point.

How We Box Ourselves In (with Software Projects)

August 28, 2013

In last week’s post I advocated that if our goal is to produce great customer outcomes (at a profit), then we shouldn’t box ourselves in. I outlined some ways that plan-driven approaches box ourselves in, such as by fully defining requirements and approving requirements up front – and then planning oriented around delivering those requirements according to an estimated schedule.

This gets ugly if someone high up in the organization has a pre-determined date in mind. Teams can get pressed into the, “What is the date that I’m thinking of?” game. But it can get ugly for other reasons. I’ll use this post to explore why traditional, plan-driven approaches go bad.

Producing Great Outcomes: Don’t Box Yourself In!

August 21, 2013

When it comes to transitioning to agile, some changes are easier than others. The easiest change to make always involves the other guy or gal; or in the case of agile, when it involves the development team and not the rest of the organization.

If everyone in the organization does not understand how agile planning differs from traditional planning, organizational friction and frustration will result because expectations are different. Agile teams will be expecting and doing one thing while other parts of the organization will be expecting and wanting to see something else.

With agile, the challenge is to: Produce great customer outcomes in the shortest amount of time possible – using the least amount of effort – while creating a sustainable, rewarding, satisfying work environment.

Fundamentally, we’re striving to define, deliver, and profit – in a way that meets this challenge.

Velocity: It’s Strictly a Team Measure

August 14, 2013

But just what is velocity? It you equate velocity as a strictly a measure of speed that can be universally measured and compared, think again.

Speed measures how fast you are going, but velocity adds an extra dimension: direction. Therefore, velocity is a measure of how fast you are moving in a given direction. When it comes to agile (Scrum) teams, velocity is a measure of how fast a team is delivering value to the customer, following the direction set by the product backlog.

A few key factors that impact a team’s velocity:
  • The composition of the team and team dynamics.
  • The adaptive state of the product(s).
  • The practices (or lack of practices) employed by the team.

Three Keys to Being Responsive and Adaptive

August 7, 2013

A key benefit of being agile is the ability to adapt to rapidly changing conditions with minimal disruption and effort. As the leading agile framework in use today, Scrum provides the necessary guidance to make this happen from both a product planning and implementation perspective.

However, “It’s in the way that you use it,” as Eric Clapton’s song puts it. To be truly responsive and adaptive we need to make sure that we have all of the enablers in play, leveraging the Scrum framework for what it is: an agile framework.

What is Agile? Part Two

July 31, 2013

In last week's post I outlined some thoughts on how agile development parallels Bruce Lee’s Jeet Kune Do (JKD). This week, I’ll conclude my thoughts, beginning with how Bruce Lee created confusion with JKD.

The Confusion Factor
Martial arts styles tend to emphasize one type of combat, such as kicking and punching in Karate or grappling in Judo. However, when it came to Jeet Kune Do, Bruce Lee was adamant that he hadn’t created a new style. He hoped, he said, “…to free my followers from clinging to styles, patterns, or molds.” (Bruce Lee in Liberate Yourself From Classical Karate, September, 1971, Black Belt Magazine)

Think about that for a moment. If Jeet Kune Do wasn’t a style, what was it? What exactly would you expect to learn? And how did Lee going about freeing people from the limitations of existing styles? How does this relate to agile?

Well, I tipped my hand at the beginning of last week’s post: JKD is a system for change.

What is Agile? Part One

July 24, 2013

Since I’ve been posing and answering questions lately, I thought that I would tackle a broader topic. Before reading on, what is your definition of agile? How do you explain it to people who are new to agile and want to understand more?

Agile development can be difficult for people to initially wrap their heads around because it is not a single, prescriptive process that can be mechanically followed to success. This makes it difficult to define what it means to be truly agile in a succinct, meaningful way. This in turn creates confusion about what agile is.

Interestingly enough, the confusion about what agile is parallels something that has been seen before. While the parallel is from an unexpected source, the similarities are striking (if you will excuse the pun): Bruce Lee’s method of fighting he called Jeet Kune Do (JKD). The similarities include what drove Bruce Lee to create JKD in the first place, what JKD is really all about, selling/marketing change, and something that what we need to be mindful of as we move forward with agile.

What Does a Scrum Team Commit To?

July 17, 2013

I mentioned in last week’s post that teams commit to a Sprint. The context of this statement involved tasking out User Stories so that the team understands the nature of the work and what need to be performed, the skills required, and an estimate on how much time it will take to complete that work. My point was that the team’s confidence in meeting its Sprint commitment by tasking out the work.

There are two things wrong with this:
  1. The most current Scrum Guide changed its wording from prior versions. What was a Sprint commitment is now a forecast. (My memory failed me on this point as I wrote last week’s post. Old habits die hard!)
  2. It was misleading for me to strongly associate tasking User Stories with achieving a Sprint forecast because in practice I favor committing to a Sprint Goal, which is in alignment with the current Scrum Guide.

Should We Task Out User Stories?

July 10, 2013

Since I addressed the question Can We Skip the Retrospective? last week, I thought I would tackle another issue this week. This time I’m exploring whether teams should task out User Stories and estimate the hours it will take to complete those tasks.

Before reading on, what would your immediate response be to this question?

One argument is that tasking User Stories creates unnecessary overhead. If teams are working on small, Sprint-sized User Stories, then these stories are all that the team needs to track, progress-wise.

Another argument is that tasking the work and estimating the time it will take to complete those tasks is a step backward, because time-based estimation techniques are we’re trying to get away from with agile.

Finally, there is the point that tracking time spent on tasks does not add any value.

Can We Skip the Retrospective?

July 3, 2013

This question seems like it has been surfacing more lately, perhaps because agile (Scrum) adoptions are increasing. This happens to involve one of those timeless qualities of an agile organization: continuous improvement.

Asking a team what it means for them to be agile and guiding them back to the Agile Manifesto is helpful in these situations. As one of the principles states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

The Ultimate Expression of Adaptability

June 26, 2013

My recent Timeless Agility post prompted my friends at Ephlux to reach out to last week to explore the post in greater detail on a recorded Google Hangout session. I talked with Regional Director Martin Harvey for a little over twenty minutes, expanding on some material and answering questions that my post prompted.

Martin asked a really great question on why the rest an organization needs to understand agile, above and beyond the fact that stakeholders could see working software much more often. My response was that seeing working software being delivered on a regular, incremental basis was the easy change when it comes to adopting agile.

You can view my entire conversation with Martin below:



Or click here to view it on the Ephlux website.

Bridging the Gap from Doing Agile to Being Agile

June 19, 2013

I’ve been iterating over a simple agility model the past few weeks, and after some additional reflection I determined that last week’s revision did not work for me. I decided to use this week to simplify the model, capturing what I want to represent as fundamental agility:


The center represents how agile is built on a foundation of a lean and learning organization; wrapped around the center are the interrelated personal, team, and organizational entities that need to support agility by understanding and adopting the values and principles from the center.

Specific implementations such as Scrum or XP aren’t a part of this model, which helps to differentiate that the various frameworks, practices and techniques are tools that support agility because they don’t make you agile any more than picking up a hammer makes you a carpenter.

The Fundamental Principle for Applying Agile

June 12, 2013

I’ve presented an agility model in my past couple of posts, with the intent of this model to provide a means to explore what it means to be agile. After a little more thought, I feel that I need to add a couple of things. First, I want to strengthen the model to provide greater clarity:


The core now explicitly lists the three foundational components:

Changing the Agile Conversation

June 5, 2013

In my last post on Timeless Agility, I introduced a simple model that I want to use as a tool in my Foundations for Leading Agile Change course that I’m developing:


Not only do I want to use this model as a learning tool, I want this to be a tool to change the conversation. And what conversation is that?

Timeless Agility

May 29, 2013

Agile has its own articulated values and principles that are built upon the principles of lean and learning organizations. And while there are various frameworks, practices and techniques that support agility, we need to understand they are tools that have the potential to change over time.

And while tools help, they aren’t the complete picture. By way of analogy, I can wield woodworking tools and hack something together (you don’t want me building your house, trust me!), but I’m not in the same league as my brother-in-law who is an excellent carpenter (you want him to build your house or high-end custom cabinets, he can do either). His understanding of woodworking transcends understanding what tools to use for which task, and the same tools in his hands will yield very different – and far greater results – than anything that I can do.

Product Owner Effectiveness Contributes to Agile Effectiveness

May 22, 2013

Scrum is the predominant agile framework in use – with 72% of the respondents in VersionOne’s State of Agile Development Survey for 2012 reporting that they use Scrum, a Scrum/XP hybrid or Scrumban. Since Scrum doesn’t prescribe technical practices, it’s good to see that Scrum/XP hybrids are in use and that the use of various technical practices is continuing to grow.

It is equally comforting to see that those who know most about agile are in the ScrumMaster role, since the ScrumMaster is responsible for guiding the team in agile practices. However, those closest to the work of the team – from a software development perspective – were ranked as most knowledgeable about agile. Those closer to the business such as executives and Product Owners were ranked as least knowledgeable.

This is a concern. A Product Owner should be interacting with the team on a daily basis; and it seems to me that if a Product Owner is in fact engaged with the team that some knowledge about agile practices and behaviors should be rubbing off. At the very least, Product Owners should have an understanding of and be supporting the values and principles of the Agile Manifesto.

Leading Agile Change – I’m Preparing a New Course

May 15, 2013

For most organizations, agile is a large change in cultural belief. We need to guide change in ways that will not only challenge existing beliefs about what works, but gain acceptance for these new practices in the process.

The ADKAR change management model tells us that:
  • There must be awareness of the need for change, followed by…
  • The desire to make change happen – along with participating in and supporting change.
Adopting agile is about moving from a current state to a new, desired state. This can and most often should start at the team level, with those who have the awareness and desire to make a change in the first place. We need to drive some initial success so that other individuals and organizations at large can see that will work in their organization.

But this is only the start of what will be a continual communication/feedback loop with the organization. In order to change the cultural beliefs of an organization, there will need to be more information flowing other than a working demonstration of a few agile teams working in isolation.

Automotive Metaphors for Lean and Agile Software Development

May 8, 2013

I read a lot, and as I’ve read various books on lean and agile topics I’ve noticed some authors occasionally using automotive metaphors or examples that are useful in making their point. While these don’t cover all the nuances of lean and agile development, I thought it would be nice to compile my notes in one place – and perhaps I’ll and some visuals and weave this approach into my courses that I’m developing as well!

Delighting the Customer
Lean and agile development is all about flowing value to the customer. The first principle of the Agile Manifesto states: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

I’m Ready to Start Contributing to Agile Adoptions!

May 1, 2013

Today marks my first day as an independent agile coach and trainer. You can call me either unemployed or self-employed, but the cold hard facts are that as of today, I don’t have an income stream. I’m planning to change that, of course! (Since I’m not independently wealthy, I will need to change that before too much time passes.)

To quote Steve Jobs, I want to “make a dent in the universe.” The agile universe, anyway. Maybe it will be only a nick or scratch, but I am pursuing my passion. I believe in agile and that companies and people have a lot to gain by adopting agile, enough so that I’m willing to put a stake in the ground and get out in the market to help make agile adoptions a positive, successful venture.

Preparing for the Next Phase of My Agile Journey

April 24, 2013

This is my last full week at my current job. In fact, next week’s post will mark my first day as an independent agile trainer and coach. I don’t have any gigs lined up just yet, but I have some feelers out. In the meantime, I’ve been spending all of my spare time preparing. And I’m sure that I will need some additional time to finish some things that I have in progress right now.

As I discussed in a post at the beginning of this month, I’ve named my company and registered with the state. I have a logo. I also have a web site and I’ve added my company on LinkedIN. I worked with a local sponsor to put on our first Maine Agile Gathering. Since that event all of my spare time has been dedicated to putting a couple of training courses together to complement my coaching services.

These courses are proving to be an interesting exercise! Just the other night I changed my original direction (my web site does not yet reflect this thinking, either); given the local market need and thinking about my last post, I’ve determined that it would be a good idea to have a one-day Agile and Scrum team course. Since agile adoptions are just getting under way in my local area, this will serve a broad customer base comprised of companies that need to get teams up and running quickly.

Serve Your Customers, but Make Sure to Serve the Market

April 17, 2013

Wayne Gretsky – nicknamed The Great One – has been called the greatest hockey player ever. (With a nickname like that, would you expect anything different?) Gretsky became great because of his highly developed understanding of the game and his ability to read the game as it unfolded. Gretsky always strove to, "skate where the puck is going, not where it's been."

The same applies to bringing a product or service to the market; and to do so you need to listen to the market as whole, reading where it will be. And keep in mind that your assumptions about the market could very well be wrong. Even experts get things wrong.

Success with Our First Maine Agile Gathering!

April 10, 2013

I'm delighted to report that our first – and I’d say that it is safe to say we’ll do this again – Maine Agile Gathering was a success in every way. Our speakers were fantastic (Dan Mezick, Dan LeFebvre, and Bill Joiner), the venue was superb (Portland Country Club), and the promotion by our Sponsor (Pro Search, Inc) helped us to draw over 100 attendees from a variety of Maine-based companies.

By design, this was a half-day morning event that was scheduled to end at noon, with breaks between each speaker. We missed by 15 minutes, which wasn’t all that bad – except that the room was getting a little warm by that point…Although people may have been a little anxious to get back to finish out their work day, everyone pretty much hung in to the end. And I always wonder how many people told their colleagues that this was an all-day event.

I’m Going Independent!

April 3, 2013

As I mentioned in my last post, I’m going independent as an agile coach. I’m so passionate with all things agile that this move makes greater sense to me each and every day. And considering the increased interest in agile with Maine-based companies where I live, I’m hoping my timing is right. By all appearances it is, so I’m optimistic that I’ll be working quite literally in my own backyard.

I won’t make the official cut until the end of the month because I have an agreement to remain with my current company until that time. But I’ve been spending my spare time getting ready. I’ve named my company and filed paperwork with the state. And I have a logo. I’ve also started on a web site and began putting a couple of training courses together to complement my coaching services.

My Agile Career and Adapting to the Winds of Change

March 27, 2013

I’ve spent the last 8 years in an organization that transformed itself to agile. This transformation began slowly, initiated by a team that approached me (I was our Director of Development at the time) about trying agile. I said, “Yes,” and our journey began!

Long story short, we moved our entire organization here in the Portland, Maine office to Scrum. We didn’t stop by making agile “something for the development teams.” As a management team, we embraced agile and transitioned our management approach to a servant leadership model. We read, experimented, sent people to conferences, brought in trainers/coaches, and we learned from both our successes and failures. (We did managed to screw up very now and then!)

Our First Maine Agile Gathering!

March 20, 2013

Given the increased interest in agile development in local Maine-based companies (I live and work in Portland, Maine), I was approached earlier this year about putting together an agile event. Since this is our first event, Pro Search, our sponsor, wanted to make it as attractive as possible for people to attend. They offered to make this a free event! We also settled on making this a half-day event to minimize the impact to work schedules.

We’re hoping that is will be our first annual Maine Agile Gathering on Friday, April 5th. We have some great speakers lined up:

Dan MezickDan LeFebvreBill Joiner

I own a great deal of thanks to these individuals who agreed to speak at this event. For anyone in the Portland, Maine area who would like to attend, please register in advance. (We need to plan space, and we are offering free breakfast as well!) I hope to see you there!

Agile is the Solution to a Critical Gap

March 13, 2013

The American Management Association (AMA) published a 2012 Critical Skills Survey that states, according to the U.S. executives polled, that the American workforce is average – at best – at the “four Cs” of Critical thinking, Communication, Collaboration and Creativity. The view of these executives is that the American workforce needs to excel at these four Cs in order for businesses to grow in the 21st century.

I don’t disagree that those are critical skills. However, there is a gap between what these executives are saying and what is happening on the ground. Tony Schwartz summed up this general sentiment in his book, The Way We’re Working Isn’t Working:
“The all-too-common dynamic in today’s workplace is parent-child. Most employers tell employees when to come to work, when to leave, and how they’re expected to work when they’re at the office. Treated like children, many employees unconsciously adopt the role to which they’ve been consigned. Feeling disempowered and vulnerable, they lose the will and confidence to take real initiative or to think independently. Doing what they’re expected to do often becomes more important than doing what make most sense, what’s most efficient, or even what might create the highest value.“

The Agile Family

March 6, 2013

How do you think kids would respond to the following question? “If you were granted one wish about your parents, what would it be?” Ellen Galinsky of the Families and Work Institute asked this very question to 1,000 children, and the number one response was that kids wished that their parents would be less tired and less stressed.

Work/life balance can certainly be a challenge. So how can we reduce stress while doing a better job of drawing our family closer while preparing our children to enter the world? Author Bruce Feiler thinks he has the answer, and he found it when he encountered a family in Hidden Springs, Idaho.

VersionOne’s State of Agile Survey for 2012 is Out!

February 27, 2013

I received an email yesterday that VersionOne’s State of Agile Development Survey for 2012 was ready and I immediately grabbed my copy. It’s always interesting to see how agile development is progressing and where the challenges are.

On the plus side, this survey indicates that agile continues to have legs, with future plans to implement agile increasing from 59% last year to 83% this year, along with an increase of organizations with 5+ agile teams (48% this year compared to 33% last year).

Crunch Time: If You Play, You Pay

February 20, 2013

Wiktionaryx defines crunch time as, “A critical period of time during which it is necessary to work hard and fast.” We’ve all faced deadlines and for various reasons, when work has piled up and we need to suck it up and get things done. And this may very well mean working longer hours than usual.

Do we get a productivity boost from overtime? Yes, but we need to make sure that we limit this overtime to short bursts of a few weeks. And there is a trade-off involved; as Daniel Cook says in a great productivity presentation, “When you crunch, you pay.”

Spiraling Up Towards Agility

February 13, 2013

My last post introduced an upward spiral of change from the book Changeology: 5 Steps to Realizing Your Goals and Resolutions by John Norcross and Kristin Loberg. This spiral illustrates a progression of 5 steps related to personal change and how people iterate through those steps, progressing in a non-linear fashion. This is because Norcross and Loberg acknowledge that we’ll make small slips along the way, reverting back to old habits in small ways as we implement change.

The same process is followed as people and teams strive to become agile. They iterate towards greater agility over a period of time, undergoing continual change as they learn more about what it means to be agile and as the team collectively shifts its very thinking about work and its approach to work. And there will be slips back to old habits and ways of thinking along the way.

For example, a team might start out by learning the Scrum framework, learning how the Scrum artifacts, ceremonies and roles are designed to facilitate a self-managed team in delivering software in short sprints. As the team continues to learn and improve, they will look to add technical practices, doing so in ways that support agile thinking.

The Upward Spiral of Successful Personal Change

February 6, 2013

A downward spiral is a pattern of self-destruction that is repeated over time until we reach a BAD PLACE. Downward spirals are not deliberate choices and actions designed to reach that BAD PLACE. After all, no one really commits to a gradual journey of succumbing to temptation and implementing behavior designed to take them to that place, do they?

But you can end up in that BAD PLACE, and once you are there, you may wonder how you got there. If you’ve been self-aware enough to understand that you have been doing things all along that could lead you to that BAD PLACE, you may ask yourself why you allowed yourself to do those things and why you didn’t take action to change before you arrived.

Perhaps you tried to change, but it didn’t stick. How often do people quit smoking only to resume it later? Or go on that crash diet only to re-gain the weight again? How many of those gym memberships that people signed up for in the New Year are destined to go idle any day now?

Fake It Until You Become It

January 30, 2013

Small changes – tiny tweaks – can lead to big changes. How would you like to make a two-minute change that greatly improves your odds of success in a job interview? Or strengthens your ability to actively participate on the job or in the classroom? An interesting TED Talk by Amy Cuddy reveals how.

As a social psychologist Amy Cuddy became interested in how nonverbal expressions played a role in power dynamics. After conducting studies, Cuddy found that certain body postures – “high-power poses” – lead to hormonal changes that configure our brains to be assertive, confident and comfortable. Likewise, “low-power poses” can do the opposite, making us fell stress-reactive and shut down.

In other words, our own non-verbals govern how we think and feel about ourselves. As Cuddy says, “Our bodies can change our minds.” She found that power posing for just a few minutes can change our lives in meaningful ways.

Become a Learning Organization, Not a Copycat

January 23, 2013

It’s not uncommon that companies copy tools and techniques used by other companies, hoping to duplicate the other company’s results that they have observed or learned about. Unfortunately, this copying is too superficial to provide transformational results. Something is left behind.

When it comes to agility, it is more accurate to say that there are interrelated somethings that are left behind. And those are the key leverage point: the mindset and behaviors of being agile.

Our behaviors are driven by our beliefs and values – our mindset – that Dan Mezick has articulated very nicely in his book The Culture Game: Tools for the Agile Manager. (Read more about the Results Pyramid in my post, Adopting Agile: Seeing is Believing.) As I stated in the close of my last post, transitioning to being agile places a focus on changing existing patterns of thinking and behavior that, little by little, change an organization’s culture.

The Challenge in Becoming Agile

January 16, 2013

Agility “…is a quality of the organization and its people to be adaptive, responsive, continually learning and evolving.”Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum by Craig Larman and Bas Vodde
I used this quote in a talk that I gave last year at one of our Maine Agile User Group meetings, and it captures something vitally important: Agility is a quality of the people and the organization. And herein lies the real challenge with agile adoptions.

All too often we as individuals – and as collective organizations – reach for the prescriptive fix. Tell us what process we need to follow or what plan to follow, and we’re ready for action. This translates to improving by copying the practices of others, using the same tools and techniques in the hopes that we will transform our results. But we do nothing to actually transform ourselves.

A Management Lesson from an Unusual Source

January 9, 2013

This past summer we acquired a new family pet – a dog that my wife named Sammy. (And not a popular choice with our cat, Lexie, but she adapted.) He’s a good dog, and he seems pretty smart. He picked up on how to sit and play fetch without much instruction at all.

But Sammy is an energetic little guy, and he can get carried away when people come over to the house, as in he tends to jump all over them. He eventually settles down, but we thought that it would be a good thing to take Sammy to obedience school.

The trainer started the course out by explaining some basics. As the trainer described today’s training approach in comparison to yesterday’s approach, I couldn’t help but wonder about why we haven’t been as good about managing humans.

How to Meet Our Resolutions (Commitments) in the New Year

January 1, 2013

It’s a New Year and absolutely nothing happened on Dec 21, 2012 (other than a galactic alignment that did not herald the end of the world)… Since we’re all still here, did you make a New Year’s resolution?

A New Year’s resolution is a commitment – a personal commitment – that an individual makes to do something new and constructive, like reforming a bad habit or achieving a personal goal of some sort. An interesting question to ask is: What are the success rates of New Year’s resolutions?

Not great, according to a New Year’s Resolution Experiment conducted in 2007 by British psychologist Richard Wiseman. The experiment tracked over 3,000 people with a range of resolutions, including weight loss, exercise, quitting smoking, and drinking less. Out of these 3,000+ individuals, only 12% achieved their goal.