Software Results

Product Owner Effectiveness Contributes to Agile Effectiveness

noreply@blogger.com (Dave Moran) — Wed, 22 May 2013 13:54:00 +0000

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.

Whenever I’ve worked with struggling teams, one of the first areas I look at relates to the Product Owner and the product backlog:

Does the Product Owner understand the principles of crafting good user stories (e.g., INVEST in good stories)?
Is the Product Owner collaborating with the team about the intent of the user stories and defining the actual solution? This is in support of one of the principles of the Agile Manifesto: “The most efficient and effective method of communicating to and within a development team is face-to-face conversation.”
Is the Product Owner attending the daily standup and readily available to the team to answer questions? This is in support of another principle of the Agile Manifesto: “Business people and developers must work together daily throughout the project.”
Is there a prioritized, groomed product backlog?
Does the Product Owner understand that the daily standups and sprint demos are essential feedback mechanisms (feedback loops)?

I’ve often seen poorly-performing teams struggling with issues such as:

Comprehending the backlog (the work is ambiguous or poorly articulated), leading to disengagement.
An unavailable Product Owner – the team is either delayed in getting timely answers that impacts velocity, or they are forced to make their own calls that need to be reversed later, creating unnecessary rework.

I’ve worked with disengaged teams that became very engaged once we cleared up the expression of user stories in the Product Backlog, usually done by going back to the usual template:

AS A [type of user] I NEED (OR WANT) TO [perform some task] SO THAT [benefit]

Once the team understands what the user wants to perform and anticipated benefit of performing that task – free of implementation details – the team typically becomes very engaged about crafting a solution. The challenge in an agile context is that teams should be striving to meet the need as simply as possible, as articulated by another one of the principles of the Agile Manifesto: “Simplicity – the art of maximizing the work not done – is essential.”

Even if Product Owners get the need for clear articulation of the work, those used to a more traditional software development approach fail to realize that user stories are not full requirements, but expressions of intent that should be elaborated on just-in-time basis. And even when the user stories are elaborated via a conversation with the team, there will be a need to respond to questions as the team works through the details during a sprint because small adjustments will need to be made.

Sometimes the need for bigger adaptations will arise. Consider the following scenario: A user story is discovered to be much larger than planned as the team works on the story in mid-sprint.

This is an opportunity to make an important call because the cost/benefit ratio has shifted. Perhaps this user story is no longer valuable to do and should be jettisoned in favor of starting work on other user stories, reducing the Cost of Delay of these stories. Another call might be to pull this user story from the current sprint and add a spike to a future sprint to determine if is there is another approach can be taken. (Discussing the situation with the customer should also occur.)

In order for teams to be productive, they need real-time responses to their questions. With just one day of wait time in a two-week sprint that is imposed by a lack of Product Owner availability, the team takes a 10% hit. Short cycles are an intrinsic part of agile delivery, as expressed by two other principles of the Agile Manifesto:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

And agile teams need to be focused on delivering working software, as yet another principle of the Agile Manifesto clearly states: “Working software is the primary measure of progress.”

As you can no doubt gather from the points above, Product Owners should be supporting all 4 values of the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Leading Agile Change – I’m Preparing a New Course

noreply@blogger.com (Dave Moran) — Wed, 15 May 2013 12:34:00 +0000

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.

For a start, there needs to be visibility so the project(s) that new agile teams are responsible actually get the attention of organization so that management becomes aware of the need for change. Agile teams can provide valuable knowledge and information about how to change along with modeling what the change looks like.

There definitely needs to be someone championing how agile differs from other approaches along with why they work. Without this, agile adoptions risk becoming an incremental change where specific practices are utilized without making the fundamental shift in the mindsets and behaviors required to make agile a transformational change. You don’t want your Scrum Sprints to be viewed as a series of mini-waterfall projects, do you? This can happen…

This is why I’ve been spending a great deal of my time putting together a Foundations for Leading Agile Change course. This will be a two-day course that introduces Lean and agile, taking participants through a series of exercises, discussions, and information-sharing designed to create an understanding of Lean and agile before discussing Scrum and Kanban.

My goal is to provide a solid understanding of the fundamentals, helping executives, managers, and project managers – and anyone else who is taking the lead in agile adoptions – not only understand what agile teams are really up to, but create awareness and desire that motivates them to get behind and support a gradual organizational shift towards a new future state. And I’ll sprinkle in information about guiding change along the way.

My hope is that this course will help to fill a needed gap in the marketplace. (Otherwise, this has been nothing more than a personal intellectual challenge, but I still consider it worth it in terms of my own continual professional development.)

Granted, implementing agile change will need to be an iterative process in practice, but based on my materials that I’ve prepared thus far I can equip individuals with a strong foundation and understanding to work from in the space of a couple of days. Of course, the real test will be that first run through! (TBD)

Automotive Metaphors for Lean and Agile Software Development

noreply@blogger.com (Dave Moran) — Wed, 08 May 2013 15:13:00 +0000

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.”

How do we satisfy (or as Steve Denning says, delight) the customer? In a way that is profitable and competitive? Richard Rumelt provides this guidance in Good Strategy Bad Strategy: The Difference and Why It Matters:

“Form an image in your mind of the BMW’s driver; see her taking the curves on the winding Angeles Crest Highway. Look at her face and imagine sensing her pleasure or displeasure with the automobile.

“Now, begin to vary the design. Make the car bigger, quieter, a bit less responsive but more powerful, heavier. Now, lighter, quicker, more responsive. To do so, you have to change the chassis, the engine weight and torque, the suspension, the steering assembly, and more. It will sway less and hug the road; the steering wheel will provide more tactile feedback. Now adjust the chassis: make it stiffer to dampen longitudinal twist and soften the front suspension just a bit to reduce road shock. Varying forty or fifty parameters, you will eventually find a sweet spot, where everything works together. She will smile and like her car.

“But there is more. Her driving pleasure depends upon the price paid, so we begin to include cost in our design. We concentrate on her smile per dollar. Many more interactions must be considered to find the sweet spot that gives the largest smile per dollar.

“You cannot search the entire space of possibilities; it is too complex. But you can probably, with effort, produce a good configuration. To get more sophisticated, you should also include the pleasure the driver takes in buying a premium brand, backed up by image advertising and swank dealers. You should also consider her buying experience and the car’s expected reliability and resale value. More design elements to adjust, more interactions to consider. And then, of course, you should consider other drivers with other tastes and incomes, a huge step upward in complexity and interaction.

“Yes, we went beyond product to include manufacturing and distribution in the design, but our strategy was tuned to please the customer, not to deal with competition.

“To deal with competition, expand your vision again to include other automobile companies. Now you are looking for a competitive sweet spot. You have to adjust the design—the strategy—to put more smile per dollar on a driver’s face than she can get from competing products.”

Vision and Planning
One benefit of lean and agile development is unlocking the potential of people. A shared vision provides a means to energize people and provide direction. Peter Senge discusses the importance of a shared vision in his book The Fifth Discipline: The Art & Practice of The Learning Organization:

“A shared vision, especially one that is intrinsic, uplifts people’s aspirations. Work becomes part of pursuing a larger purpose embodied in the organizations’ products or services—accelerating learning through personal computers, bringing the world into communication through universal telephone service, or promoting freedom of movement through the personal automobile.”(Italics mine)

In addition, while small companies tend to travel down one road, they may need more options – new highways – as they begin to grow. Michael E. McGrath shares his perspective in Product Strategy for High Technology Companies:

“A rapid-growth company is more aggressive, but it doesn't travel just one highway. Instead, it invests in a broad portfolio of product development projects. It invests in some of the highways for growth identified in the proactive process, but it also continues to invest in maintaining the competitive position of its current product offerings. The increased investment in R&D pays off once the company begins growing rapidly.

“A stronger competitive position can sometimes be a highway to growth, but frequently the result is an increase in revenue. Adding improvements that make products better than those of competitors is always a good defensive strategy, and may be necessary to keep competitors from taking away market share.

“In a new, rapidly growing market, a winning and sustainable vector of differentiation will provide a highway to growth. By continually focusing on improving its products along its vector of differentiation, an integrated customer solution, SAP grew rapidly from 367 million DM in 1989 to 8.5 billion DM in 1998. The key to such growth is the ability to sustain the “competitive advantage of a successful vector of differentiation. Once this advantage is lost, then it ceases to be a growth highway even in a growing market...”

Estimating
In their book Rework, Jason Fried and David Heinemeier Hansson state what is solidly recognized in lean and agile circles: “We’re all terrible estimators. We think we can guess how long something will take, when we really have no idea.”

They continue, talking about how we can underestimate simple things like how long a trip to the grocery store will take and pointing out just how far off we can be at times: “Plus, we’re not just a little bit wrong when we guess how long something will take—we’re a lot wrong. That means if you’re guessing six months, you might be way off: We’re not talking seven months instead of six; we’re talking one year instead of six months.

“That’s why Boston’s “Big Dig” highway project finished five years late and billions over budget…”

Capacity and Flow
As experienced lean and agile practitioners understand, planning to utilize “resources” (people) at 100% capacity is a BAD PLAN because flow will be impacted. In his book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Dean Leffingwell urges us to “Think of a highway system at rush hour.”

He states that “…when a system is loaded to capacity, it can become unstable, and the problem is compounded. In heavily loaded systems, larger batches move disproportionately slower (throughput decreases) through the system. “(Or highway in the case of the automotive metaphor.)

What we need something to deal with the variability that we inevitably encounter in software projects. Tonianne DeMaria Barry and Jim Benson cover this in their book, Personal Kanban: Mapping Work | Navigating Life:

“Consider what makes the roadway flow. Is it the cars, or the space between the cars? If there were no cars, there would be nothing to flow. If there was no space, the cars could not move. It’s that balance between cars and open space that gives us flowing traffic. That open space is called ‘slack.’ We need slack in our workflow, we need space to adjust. Without slack, we will overload.”

Oversight and Governance
Lean and agile oversight and governance is done with a light touch. We want as much self-management as possible, not constrictive control. But there are boundaries that need to be drawn. While we want to promote freedom of movement, we want to ensure safety, much like a speed limit sign does. (Provided people follow the speed limit.)

Richard Rumelt, in Good Strategy Bad Strategy: The Difference and Why It Matters, advises us to implement frameworks and policies that act “Like the guardrails on a highway, the guiding policy directs and constrains action without fully defining its content.” (Scrum is a great example of a framework that guides teams without being overly prescriptive.)

And we do need to take care about the boundaries that we draw, as Donella H. Meadows cautions us in Thinking in Systems: A Primer:

“When you draw boundaries too narrowly, the system surprises you. For example, if you try to deal with urban traffic problems without thinking about settlement patterns, you build highways, which attract housing developments along their whole length. Those households, in turn, put more cars on the highways, which then become just as clogged as before.”

Progress and Metrics
When driving a car, progress is a measure of how far down the road you have traveled, just as “Working software is the primary measure of progress,” as one of the principles of the Agile Manifesto states. The act of driving a car involves – as Tonianne DeMaria Barry and Jim Benson state in Personal Kanban: Mapping Work | Navigating Life – a combination of things:

“Situational knowledge is seeing the road, metrics are the gas gauge. Visualizing work combined with metrics provides a full understanding of the current situation.”

The point is excellent. We don’t blindly follow our gauges alone when we drive, do we? Yet we tend to rely on metrics alone to “drive” our companies. Josh Linkner points out this problem in his book, Disciplined Dreaming: A Proven System to Drive Breakthrough Creativity:

“We use complex models, historical data, and buzzwords like ‘key performance indicators’ and ‘balanced scorecards.’ Like dashboard instruments, these tools are great, but they're not the one-and-only factor in creating success. We hire team members for their judgment and creativity, but often relegate them to merely following systems mechanically.”

(I have to confess Josh’s metaphor was actually one of flying a plane, but I took a little liberty to pull this into the mix, since he makes a great point.)

Commitment and Competence
When agile software teams make an iteration or sprint commitment, teams need the desire and ability to execute and realize that commitment. James Flaherty gives us this perspective in his book, Coaching: Evoking Excellence in Others,3rd Edition:

“I think of commitment as if it were the engine of a car. It doesn’t matter how powerful the engine is, or how well tuned up it is, or how much gasoline it is getting if it is not connected to the wheels by the transmission. The transmission is a metaphor for competence. This competence takes many forms: sometimes it is skill, as in learning how to fly a plane; sometimes it’s a capacity to observe ourselves and not become defeated by negative emotions or self-assessments.”

And what if a software team isn’t meeting the needs of the business? There are a lot of drivers here, covered at a high level in the Agile Manifesto. Sometimes the easy answer isn’t always the right answer, as Dean Leffingwell points out in Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise:

“And although it’s true that we want to absolutely need to create product flow, where input does match output, we can’t simply achieve flow by just ‘backing off the accelerator,’ or fewer cars will do down the freeway than it has capacity for. Yes, it’s flowing, but it’s too slow. Rather, we want to accelerate to the point of most efficient productivity, the point just below which congestion (in this case as witnessed by a combination of overloaded, multiplexed teams and badly matched expectations) occurs.

So, it could be that you need more capacity (another team), but teams also owe the business to be as finely tuned and efficient as possible, hence the reason for a couple of other principles in the Agile Manifesto:

“Continuous attention to technical excellence and good design enhances agility.”
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

In effect, we are regularly tuning the engine while driving. But that is where effective – and real – learning takes place, as James Flaherty tells us in Coaching: Evoking Excellence in Others,3rd Edition:

“No one can learn to drive a car simply by learning the language of automobiles and traffic laws. After learning that language we must get behind the wheel, spending many hours practicing driving. It’s only by this continual, focused, intentional practice that we become competent drivers.”

Adaptability and Flexibility
The final word comes from Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo, advising management to move “from ‘our way or the highway’ to flexibility.”

I’m Ready to Start Contributing to Agile Adoptions!

noreply@blogger.com (Dave Moran) — Wed, 01 May 2013 18:18:00 +0000

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.

Based on the research that I’ve seen and my own observations, agile adoptions are increasing, and all indicators are that I am in that sweet spot of aligning my passion, expertise, and market need to provide my highest point of contribution:

(Diagram from The Disciplined Pursuit of Less by Greg McKeown, August 8, 2012, Harvard Business Review)

I’m going to spend the next couple of weeks or so finishing off my courses (I have an excellent start thanks spending most of my free time this past month working on them), writing a white paper or two (I have some ideas), and connecting with some potential prospects. From there, I’ll have to see how things progress.

The worst-case scenario is that I’ll be contributing to my own professional development, but I really want to contribute by working with others in their agile adoptions – that’s where the real fun is! But since I enjoy this so much, it won’t feel like work.

Preparing for the Next Phase of My Agile Journey

noreply@blogger.com (Dave Moran) — Wed, 24 Apr 2013 10:42:00 +0000

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.

I had already determined that a course for executives and managers would be beneficial, particularly since the Top 3 Barriers to Further Agile Adoption are:

Ability to change organizational culture
General resistance to change
Trying to fit elements into a non-agile framework

(From VersionOne’s State of Agile Development Survey for 2012)

My intent all along was to develop a course for executives and managers. Now that I’m adding an “Agile and Scrum in One Day” course, I’ve determined that I can cover similar topics in each course, providing internal consistency between the two.

What will change is the depth of coverage in certain topics. I’ll obviously spend much more time on the Scrum framework in the Agile and Scrum course, with less time devoted to organizational change. I’ll reverse the focus in the Foundations for Leading Agile Change course, providing much more coverage on organizational change as it relates to agile, with only a minimal amount of coverage on Scrum.

The courses aren’t complete yet, but they are beginning to take shape. I have a clear goal in my head as to how these will work together and what the content for each should contain. I have to say that adding this one-day course actually sharpened my focus, and I’m thinking that result will be a couple of great, complimentary courses on agile. I’m satisfied that these two courses – plus a half-day personal productivity course – will be enough to start with!

I’m grateful that I’ve spent the last 3+ years blogging and writing on agile topics. This has been a big contributor to my preparation in going independent. I began blogging because I like to write, but I also wanted to develop my understanding and thinking on agile leadership – above and beyond what I was doing in my regular job. The process of writing a weekly blog post (bi-weekly for a while, just to prove to myself that I could do it), plus guest posts on other blogs and an occasional magazine article incented me to read, experiment, observe more than I would have otherwise.

When I step back and think about it, I really started preparing for this moment three and a half years ago. All of those notes and research that I used in my writing are paying dividends as I prepare my courses. Now I’m just pulling everything together as I move into another phase of my agile journey. Like everyone says, agile is a journey, not a destination!

As I look forward, I’m confident that I can provide real value to other organizations adopting agile, and I’m looking forward to that first engagement!

Serve Your Customers, but Make Sure to Serve the Market

noreply@blogger.com (Dave Moran) — Wed, 17 Apr 2013 11:29:00 +0000

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.

Consider the following expert opinions:

“This telephone has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us.” – Western Union internal memo, 1876.

"Who the hell wants to hear actors talk?" – H. M. Warner, Warner Brothers, 1927

“I think there is a world market for maybe five computers”. – Thomas Watson, chairman of IBM, 1943

“There is no reason for any individual to have a computer in their home”. – Ken Olson (President of Digital Equipment Corporation) at the Convention of the World Future Society in Boston in 1977

Listening to the market as a whole requires that you step back from your day-to-day dealings with individual customers to assess the larger picture. Compare and contrast your immediate dealings with a customer with your broader dealings with other customers and industry research.

Does a particular customer have a have a limited view of the world based on their immediate concerns, or are they a leading indicator of change? Do they have their own ideas about what you can and can’t do for them based on their assumptions about you? (And do you need to work on changing those assumptions?)

Serving a customer can generate some immediate revenue, but determining how to profitably serve a market creates a sustainable business. Cast a wide net and keep your ear tuned to unmet needs and motivations of the larger world. And be prepared to let go of your assumptions.

As I start down a new path with my own agile coaching and training company, this is what I intend to do. Recent surveys indicate that agile is not only here to stay, its adoption is increasing – and with that adoption there should be some great opportunities.

Success with Our First Maine Agile Gathering!

noreply@blogger.com (Dave Moran) — Wed, 10 Apr 2013 10:17:00 +0000

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.

When we scheduled the event and started drawing attendees, I was surprised to see so much interest in agile here in Maine. And because Pro Search made this a free event, the real test was in how many people would actually show up. We had 104 attendees, with a lot of new faces that I haven’t seen at our Maine Agile User Group – so I’m hopeful that we can increase our membership and attendance. I took this event as an opportunity to promote our user group, and the free coffee mugs with our Agile Maine web site URL on it should definitely help.

I personally had some wins out of this event. I saw some people from past (work) lives, and it was great to connect with them at the event and later on LinkedIN. I hope our paths will cross even more as companies adopt agile here in Maine. I’m also hoping that since I’m branching out as an independent agile coach, I can spend some quality time with people and local companies, helping to make their agile adoptions successful.

In the end, I hoping that I’ve contributed to promoting agile interest and adoption here in Maine. Time will tell!

I’m Going Independent!

noreply@blogger.com (Dave Moran) — Wed, 03 Apr 2013 10:09:00 +0000

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.

And my company is…

www.agileguide.us

(If you look at the web site, keep in mind that it is a work in progress, but I would appreciate any feedback. Send it to me at my new email address: davemoran@agileguide.us)

My intent is to guide and coach organizations on agile leadership and change. I’ve been a part of a management team that has transformed itself and our organization into an agile organization, and I dare say that if you talk to anyone who works in our organization, they will say that we have transformed into something special. We have a productive, rewarding, satisfying work experience that has proven to be routinely profitable over the years. And I want to guide other organizations so that they can have this same experience.

I genuinely believe in the transformational aspects that being agile can bring. It can transform your work, and this in turn can have a positive effect on your outlook and life. Not only that, but lean and agile techniques can be applied to your personal life by using Personal Kanban or Scrum for the family.

As I thought about becoming a full-time agile coach, I recalled that when I was in college, my part-time job was as an assistant high school cross-country and track coach. And I enjoyed coaching. It was great to coach others and see them succeed.

And I’m not talking about winning as a measure of success, either. The real wins were the kids who improved and – much to their own surprise and delight – ran faster times than they thought was possible for them to achieve. I couldn’t run for them, but as an experienced runner who studied and applied training techniques to improve my own times, I was able to coach and train others so that they were successful. I’m hoping to re-live that experience as an agile coach.

My Agile Career and Adapting to the Winds of Change

noreply@blogger.com (Dave Moran) — Wed, 27 Mar 2013 10:33:00 +0000

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!)

It was hard work that involved personal and professional change, but the results were worth it. We transitioned from having customers complain about the quality of our product to raving about how reliable it was and how they were happy to run their business with our software. In one of those great moments, I was in the room when customers pressed our corporate parent to invest more in us because of the quality of our product and the trust that we had built up with them. (Thank you, net promoters and advocates!)

We also developed a new product using agile development, generating revenue and – for several months in a row – this product was listed as the top sale in company meetings. To top it off, we accomplished this while achieving the highest employee satisfaction ratings in the company.

The agile experience has been a personal journey filled with growth for me as well. For example, I had someone who reported to me tell me that he was very critical of my management skills early on, but as I worked on servant leadership and embracing agile practices, he viewed my change as a manager as very positive.

But there are times when circumstances dictate change.

I've been considering making a move for a while now, and now is as good a time as any to make a shift. I have an agreement to remain with my current company until the end of April, but after that, I'm going independent. I’m forming my own company focused on agile coaching and training. I want to help other organizations have a positive, successful experience transforming to agile. More about my plans in next week’s post.

Our First Maine Agile Gathering!

noreply@blogger.com (Dave Moran) — Wed, 20 Mar 2013 11:00:00 +0000

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 Mezick

Dan LeFebvre

Bill 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

noreply@blogger.com (Dave Moran) — Wed, 13 Mar 2013 10:36:00 +0000

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.“

In other words, the executives in the AMA survey may be saying one thing, but they aren’t walking the walk; at least not in a majority of the companies out there. The behavior of most executives sends a strong message that they want people to “do as they are told.” Period.

This disconnect is supported by the latest State of Agile Development Survey published by VersionOne. It’s worth taking a look at some of the problems agile adoptions are experiencing because agile makes things transparent and exposes weaknesses. The current VersionOne survey cites that the leading cause of failed agile projects is that the company philosophy or culture at odds with core agile values. And the top barrier to further agile adoptions is the ability to change organizational culture.

Since agile adoptions are facing cultural challenges at the organizational level, we clearly have conflicting values at play. Organizational culture reflects an attitude and approach to work – a particular belief – in “the way we do things in order to succeed.” And today many organizations are run as plan-driven, command-and-control cultures, with the emphasis on control.

An agile approach, on the other hand, values the collaborative efforts of multi-disciplinary teams in crafting creative solutions to complex problems. Teams that will need develop and apply critical thinking skills to aide in crafting an effective solution. Finally, as part of the “agile package,” face-to-face communication is definitely valued, and I can make the case that clear, succulent, written communication is valued as well because User Stories and other agile documentation should be lightweight in nature.

So we have a situation where being agile supports everything that the executives surveyed by the American Management Association say that they want, but aren’t getting enough of. And yet agile adoptions are challenged because organizations aren’t being run in ways that actually support being agile.

So where is the problem? According to VersionOne, the least knowledgeable people when it comes to agile are executives. In fairness, executives are trying to get things done. It’s just that a shift is needed, one that requires education in order for everyone to fully understand what it takes (nothing is for free) along with the benefits that are possible in transforming to agile. I covered how agile is a cultural change in some recent posts, culminating in a post titled, A Cultural Recipe for Agile Organizations.

I firmly believe that people doing the work want to be more involved and engaged in their work, to participate in ways that will develop the four Cs. We have the solution; we just need to implement it. It’s been called other things and there have been variations on a common theme of empowerment and moving greater authority, autonomy and decision-making closer to the people performing the work, but today it is best known as agile.

The Agile Family

noreply@blogger.com (Dave Moran) — Wed, 06 Mar 2013 11:10:00 +0000

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.

David Starr – a software engineer – and his wife Eleanor have four children, ages 10 to 15. One tutors math on the far side of town, another plays lacrosse on the near side of town, one as Asperger syndrome and one has ADHD. Eleanor summed it up their lives as, “...living in complete chaos.”

How did they deal with the chaos? David’s workplace had implemented agile development, so they brought this to the home. And when they did, they found that short, 20 minute family meetings increased communication, decreased stress and generally made everybody happier to be a part of the family team.

They’ve implemented other techniques, like making work visible. There is a morning checklist that each child is expected to complete. When Bruce Feiler visited the Starrs, he observed Eleanor enjoying a cup of coffee in a reclining chair and talking with her children as they checked this list, made themselves breakfast, checked the list again, put dishes in the dishwasher, re-checked the list again, generally doing whatever chores were expected and then making their way to the bus.

Bruce was astonished, and he didn’t believe that it would work in his house. But Bruce reports that the week that he and his wife introduced the morning checklist, parental screaming was cut in half. I’d take that any day! (My kids are older now, so I can’t experiment with this myself.)

Bruce says that the big ticket change came from what is essentially a family retrospective meeting that adapts the three questions from a Scrum standup:

What worked well in our family this week?
What didn’t work well?
What will we agree to work on in the week ahead?

Everyone throws out suggestions and the family picks two to focus on. Bruce says that the kids love the process, and they come up with all kinds of ideas. Three years into it and the Feiler’s are still holding these meetings. And Eleanor counts them as her most treasured moments as a mom.

Want to hear more on this from Bruce? Check out this Ted Talk:

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

noreply@blogger.com (Dave Moran) — Wed, 27 Feb 2013 11:31:00 +0000

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).

Top 3 Reasons for Adopting Agile

Accelerate time to market
Manage changing priorities
Better align IT/Business

VersionOne states that most responses centered on better customer focus and increased productivity.

Top 3 Benefits Obtained from Implementing Agile

Ability to manage changing priorities
Productivity
Project visibility (this category saw the greatest increase in benefit, from 77% in 2011 to 84% in 2012)

70% of the respondents indicated that agile projects have a faster completion time.

Top 3 Barriers to Further Agile Adoption

Ability to change organizational culture
General resistance to change
Trying to fit elements into a non-agile framework

Organizational culture has been cited as a barrier in successive years, and is something that I covered in multiple posts in October and November of last year, summarizing my thoughts in A Cultural Recipe for Agile Organizations,

Top 3 Concerns about Adopting Agile

Lack of up-front planning
Loss of management control
Management opposition

I wonder if management opposition would decrease if there was a better understanding of the planning and empirical controls present in agile development. It seems that we have a great deal of executive management education to do.

Leading Causes of Failed Agile Projects

Company philosophy or culture at odds with core agile values
External pressure to follow traditional waterfall processes
A broader organizational or communications problem

Actually, none failed was at the top of the list, but I listed the top three reasons for actual failures. Once again, it appears culture and traditional ways of doing things have a significant impact. My takeway is that there is a stronger need to increase awareness about what agile is and how obtaining the benefits of going agile requires actual change in mindsets and approaches to work.

VersionOne added something that I really liked, quoting answers to the question, “If you could say one thing to your company president about agile, what would you say?” A couple of answers:

“Agile comes with a cultural change, or don’t do it at all.”
“Managers should be willing to listen and learn about agile. They should not look at it as an uncontrolled process.”

Read more in the full survey from VersionOne. And many thanks to VersionOne for continuing to take the time and effort each year to do this!

Crunch Time: If You Play, You Pay

noreply@blogger.com (Dave Moran) — Wed, 20 Feb 2013 11:20:00 +0000

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.”

Dan’s research tells us that we need to plan for an equivalent reduction in productivity immediately after crunch time. He graphically illustrates this as follows:

As you can see, we get a temporary boost in productivity with overtime, but if we attempt to work overtime for extended periods of time our productivity begins to reverse and it can actually go negative. And no matter how you slice it, anything over 40 hours results in a recovery period.

What about teams? In his slide deck Dan shows us how overtime will trend with an agile team:

Of course, agile teams should be embracing sustainable development, shouldn’t they?

But there is a good leadership lesson here: working an existing system harder won’t achieve sustainable, long-term gains. If you aren’t reaching your desired objectives and you attempt to compensate by demanding overtime, it is predictable that productivity will temporarily increase – giving you a comfortable feeling that you’ve righted the ship – but your gains will be short-lived and productivity will level itself out in the long run.

What are your options?

Focus on throughput. Find sustainable ways to accelerate completion rates of work by increasing collaboration, combining tasks and eliminating overhead that isn’t adding value.
Add another team to provide greater capacity.
Adjust your expectations on either the delivery date or the scope.

Spiraling Up Towards Agility

noreply@blogger.com (Dave Moran) — Wed, 13 Feb 2013 11:37:00 +0000

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.

This agile thinking is expressed in how we approach work, such as combining tasks in ways that eliminate overhead and accelerate delivery without impacting quality. Creating executable specifications that describe how the software should behave along with being an actual test to validate the correctness of the software is one example. Utilizing pair programming to design and write complex pieces of software while simultaneously conducting a design and code review as the code is being written is another.

Norcross and Loberg advise us not to rush through the Psych step to get to the later steps. You need to make sure that you are mentally ready to accept making a change. And making changes in small steps is also advisable. Taking on too much change at once can overwhelm anyone, including teams and organizations that are just starting down the agile path.

When it comes to planning (the next step after Psych), and Norcross and Loberg point out that change efforts often fail because people fail to plan. Adopting agile is really about planning for what you will do next once you've decided to go agile. Will you make use of Scrum, XP or Kanban? How prepared are the people and the organization for change? How will change be managed, expectations set, and new information and learning be communicated?

An important component of planning and change is the fact that the future is not as predictable and stable as anyone would like, so be ready to revise your plan as you move forward. As Helmuth von Moltke once said, “No battle plan survives contact with the enemy.” Or in the case of us civilians managing change, no plan survives contact with reality as we interact and engage with others. Be flexible!

Be mindful to reward each small step taken that you take towards that bigger and better destination. In Changeology, Norcross and Loberg state that, “Most complex human behavior develops this way, be it speech, exam taking, or sports. So reward yourself for the successive small steps and then up the ante slightly: give yourself a reward, say, for walking a half mile; then give yourself another reward for going three-quarters of a mile and so on.” The takeaway for teams is to celebrate their successes! Don't let positive change go unnoticed.

And be wary of using punishment, as it can leave you feeling discouraged and feeling like a failure. If used too often, Norcross and Loberg note that punishment can, “…foster certain behaviors that do nothing to reward the positive behavior and can actually trigger a whole other set of problems.” Like causing you to avoid productive behaviors and make you more aggressive in dealing with other people.

What about addressing tough challenges or aggressive targets? We can always set aggressive targets and work towards them in a positive way. Instead of agile teams asking themselves questions such as, “What is wrong with…” (our practices, teamwork, etc.) or, “Why did we fail…” (to respond to customer demand, meet a sprint commitment, etc.) they can ask themselves things like:

What can we do to improve our technical practices? Our teamwork?
How can we improve our responsiveness to our customers?
Let’s understand the reasons why we missed our last sprint commitment so that the same thing doesn’t occur in the future.

The importance on focusing on the positive was proven by one study conducted by the University of Wisconsin. (Source: Beyond Performance: How Great Organizations Build Ultimate Competitive Advantage by Colin Price and Scott Keller.) The study involved the filming of two bowling teams, where each team was given its own video to study. One team received a video that showed only its mistakes and the other received a video that showed only its successes. After watching the videos, the team that studied its successes improved its score by twice as much as the team that studied its mistakes.

So, when it comes to changing human behavior, it’s always better to focus on the positive than the negative. Heck, I recently learned that positive reinforcement is recommended for training dogs.

Another important tip from Changeology is that by the time you are in the Perspire step, you need to transition from the “rah, rah” motivational talk that is useful in the Psych step to more instructional self-talk. This applies to agile adoptions as well.

New teams that move to agile on their own accord are certainly motivated to try something new, to address the problems and shortcomings that they have most likely experienced in the past. But motivational speeches won’t help teams as they implement agile practices. They need instruction – the, “here’s what to do and why it will help you” type of talk. This is where having an experienced coach comes in handy, because being excited, motivated and committed to change will only take you so far. If you are at a loss on how to proceed, you won’t be able to sustain your change.

Finally, Norcross and Loberg tell us in Changeology that, “Virtually every research study documents the high prevalence of lapses and relapses. In our studies, 58 to 71 percent of people slip at least once in the first 30 days of Perspire. The average number of slips is a breathtaking six!” And this is with personal change.

Now consider what it takes for teams and organizations – and the friction that results as agile teams bump up against a non-agile organization – to change. Change is occurring with each individual and the collective thinking and approach to work at the team and organizational level. There will be challenges at all dimensions that will require both patience and persistence over a period of time. But it’s still worth it!

The Upward Spiral of Successful Personal Change

noreply@blogger.com (Dave Moran) — Wed, 06 Feb 2013 11:30:00 +0000

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?

There is a path to success! John Norcross and Kristin Loberg developed a series of steps to guide successful change that they call the 5 Ps. There are “5 Ps” out there for a lot of things (marketing, strategy, success, etc.) but the 5 Ps that I’m talking about in this post come from the book, Changeology: 5 Steps to Realizing Your Goals and Resolutions by Norcross and Loberg. The 5 Ps are a progression of 5 steps related to personal change:

Psych→Plan→Perspire→Persevere→Persist

You start by getting Psyched, then prepare by making a Plan before you leap into the action by entering into the Perspire step, and finally you maintain in two phases: first by Persevering through those inevitable slips that you will make on your way to full change where you are equipped to successfully maintain change, or Persist.

A key finding that Norcross and Loberg discovered after more than 30 years of research on how people successfully changed behavior is that it is extremely rare that people move linearly through the steps. The vast majority of people repeat the model three to six times before they are able to move into Persist mode for good.

This doesn’t mean that people slip all the way back to the beginning each time, having to start the cycle all over again. Successful self-changers make progress little by little, occasionally slipping back – but not all the way. They cycle through the process, gaining ground and learning from their inevitable slips. The actual path becomes an upward spiral that looks something like this:

As this model shows, there will be backward slides. But the goal is to iterate, or cycle, on a journey upwards towards a greater understanding and ultimately getting you to a better place. The difference with an upward spiral as opposed to a downward spiral is that with an upward spiral, we need to be mindful of what we really want to change and to measure our progress towards that desired end state.

Next post, I’ll cover this model in more detail as it relates to being agile.

Fake It Until You Become It

noreply@blogger.com (Dave Moran) — Wed, 30 Jan 2013 11:15:00 +0000

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.

For example, Cuddy conducted recorded tests of people going through a stressful, five-minute job interview. The candidates most likely to be hired turned out to be those who had power posed for a few minutes prior to the interview. The important variable that tilts the scale is the presence that the interviewees who power posed brought to the table.

You can use your own body language to change an outcome. Cuddy advises that before your next stressful evaluative situation to try power posing – in an elevator, a bathroom stall, behind closed doors – to, “Configure your brain to cope the best in that situation. Get your testosterone up. Get your cortisol down.”

I enjoyed this talk because it reinforced the principle of making small changes that lead to better outcomes. We need to do the same thing with agile adoptions – or should I say transformations. We need to provide ourselves with a series of small experiences and approaches to work that help us to reconsider our values that drive our behavior, which in turn leads to better outcomes.

We can all improve any change effort by following Amy Cuddy’s advice: “Don't fake it till you make it. Fake it till you become it.”

Become a Learning Organization, Not a Copycat

noreply@blogger.com (Dave Moran) — Wed, 23 Jan 2013 11:30:00 +0000

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.

An example of “agile copying” is implementing Scrum, adopting all the rituals, terms and artifacts such as daily stand-ups, burn-down charts and visible task boards, but using sprints as a series of mini-waterfall projects. In this scenario, superficially copying Scrum hasn’t allowed the team to let go of its current way of working, denying the team the real benefits of agile that are possible through an actual transformation.

We’re very used to process discipline, courtesy of the prevalent Control culture. Supporting agile – really supporting it – requires that we develop learning organizations. This challenges Control culture thinking because a learning organization is not a destination; it is a state of being. Learning and improving becomes a continuous activity of the organization and its people.

The people in a learning organization have certain qualities, as pointed out by Peter Senge in his book, The Fifth Discipline: The Art & Practice of The Learning Organization. The key attribute of people in a learning organization is that people are seeking personal mastery – striving for a “special level of proficiency.”

These people are inquisitive, committed to continually seeing reality more accurately. And in doing so, they regard themselves as part of a larger creative endeavor, where they can exert influence but not control. And just like the organizations never “arrive,” people with a high level of personal mastery never feel that they “arrive,” either. They are in a continual learning mode.

To foster a learning organization it is critical that management support learning by facilitating ways to spread knowledge laterally. Toyota calls this yokoten. And one of their ground rules is that the person who has learned something new or has discovered a way to improve a practice is responsible for sharing this knowledge.

There should be limited amount of knowledge-sharing via the command hierarchy and institutionalizing learning by capturing “knowledge” in processes or even “best” practices. What is best in an organization where continuous learning and improvement is the norm? Best is only the best for a moment in time, and perhaps only really best for a specific situation, not a universal truth that should be applied in every circumstance until someone can prove that another practice is truly better, and then forced to gain approval to implement it as a new “best” practice.

Organizations only learn through individuals. However, individual learning does not guarantee organizational learning – there can be organizational barriers that prevent this from happening. But the foundation of organizational learning is with the individuals that comprise the organization. Without individuals learning and sharing what they learn, the organization learns nothing at all.

The Challenge in Becoming Agile

noreply@blogger.com (Dave Moran) — Wed, 16 Jan 2013 11:32:00 +0000

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.

This isn’t to say that you can’t improve by using agile practices, because you can. Adopting Scrum and giving people more autonomy and control over their work will make them happier. Implementing a new technical practice like Test-Driven Development will most likely increase the number of automated unit tests available to you, allowing you to make changes to the software with greater confidence. This is doing agile to incrementally improve your circumstances.

Obtaining transformational results requires that we couple practices and new approaches to work with a mindset and genuine belief in the values and principles found in the Agile Manifesto. These values and principles need to be reflected in our day-to-day actions and behaviors and those of the organization at large. This is being agile.

A prerequisite is the desire to be agile, to start down a path personal transformation as our colleagues (and organization) are doing the same. The process can be bootstrapped by adopting practices without believing in them. If you don’t happen to believe in the benefits of being agile at first, that’s OK. But to give agile a fair shake, act as if you do, then evaluate the results and decide for yourself that maybe, just maybe, your beliefs can change.

If you cling to old ways of doing things, you will not be able to drive the real change that you are looking for. For example, many organizations want more engaged employees; they claim that they want people to take more responsibility. Yet many organizations are command-and-control organizations, operating in ways that don’t place responsibility and trust in the hands of the workers.

The organization doesn’t engage people because a select few in the organization takes responsibility for defining a prescriptive process for the masses – typically one that becomes bloated as the process attempts to address a wide range of contingencies – and then assigns tasks to the workers. This approach, coupled with an HR system that reinforces expectations and behaviors through SMART goals handed down to employees (along with judging performance later) is a recipe for a parent/child relationship, not a collaborative, engaging work environment that says, “we all have a valuable role to play in the pursuit of delighting the customer.”

Workers may discover that taking responsibility be a big change. Scrum – as a framework for self-organizing and self-managing teams – reintroduces people taking responsibility. In doing so Scrum team members will need clear definition from the Product Owner about the needs and desires of the business. However, once people understand the business objectives and have the autonomy to act, greater engagement will result.

This will bring you to another challenge: as Scrum teams work in context of traditional organizations, there will always be some pull back to the old ways. Managers must learn how to foster and maintain a new work environment, to work with people in new and different ways, to support and nudge the organization towards becoming a continuously improving, learning organization.

Transitioning to being agile places a focus on changing existing patterns of thinking and behavior that, little by little, change an organization’s culture – what we believe we need to do in order to be successful. This is where the challenge is, but it is also where the real value is.

A Management Lesson from an Unusual Source

noreply@blogger.com (Dave Moran) — Thu, 10 Jan 2013 00:00:00 +0000

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.

According to the trainer, dog training today is focused heavily on positive reinforcement as opposed to negative reinforcement. The underlying belief is that when a dog receives a treat or praise as an immediate consequence of desired behavior, that behavior will increase. (This must be very fast or they will forget what it was they were doing and are now being rewarded for.)

The trainer went on to explain that negative feedback isn’t something she uses, citing that police dog training now emphasizes positive reinforcement because no matter how well-trained the dog appeared to be when using negative reinforcement, it was repeatedly demonstrated that dogs at some point turned on their trainers. Definitely something to avoid!

I started thinking about how many managers out there feel that “management by fear” is still appropriate. Even if they don’t say it, they certainly act like they believe that employees will work better under negative pressure and uncertainty. And this flies in the face of countless research and experience that demonstrates the opposite.

For example, in their paper, Positive Affect and the Complex Dynamics of Human Flourishing, Barbara L. Fredrickson and Marcial F. Losada determined that a positive to negative ratio at or above 2.9 characterizes individuals to be in ﬂourishing state; that is, an optimal state of functioning. People in this state are more able to access their abilities, to grow and to be more productive.

You can operate using fear, but what you’ll get is compliance and not engagement. People will spend their time and energy protecting themselves and their jobs. And – as a study by Amy Edmondson demonstrates – you run the risk of having critical information withheld that hinders an organization’s ability to improve, I first came across this study in Bob Sutton’s book The No Asshole Rule

Edmondson discovered that those nursing units with the best leadership reported the most errors. Ten times as many errors. This was because nurses in poorly-run units were too afraid to report errors, even though it was vital to do so.

One question in my mind is: Have we embraced positive reinforcement more broadly for dogs than we have for managing humans?

Sammy

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

noreply@blogger.com (Dave Moran) — Tue, 01 Jan 2013 11:30:00 +0000

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.

How can we improve our odds of success? This experiment yielded some interesting pointers that can help, and in doing so the experiment highlighted some differences between men and women:

Women were more successful when they were asked to go public about their goal and told their friends and family or were encouraged to be persistent and not to give up because they had fallen back to an old habit, such as succumbing to temptation for that chocolate-laden dessert.

Men were more likely to succeed when asked to set a specific goal (e.g., lose N pounds per week versus a vague goal of “losing weight”) or focusing on the rewards, the positive outcome – the carrot – and not the negative outcome – the stick.

Actually, I believe that adopting all of this advice is great for anyone. Set a specific goal, acknowledge problems – but focus on the positive, publicly declare your intent, be persistent and don’t give up, and build a support network to help you achieve your goal. And to help balance your personal and professional demands to further increase your odds of success, give Personal Kanban a try.

Finally, I would add that you should find a way to celebrate and reward yourself when you achieve your goal – in a way that won’t undo all of your hard work!

Have a Happy New Year and I wish everyone the best in 2013.

Happy Holidays!

noreply@blogger.com (Dave Moran) — Wed, 26 Dec 2012 11:10:00 +0000

It's the end of another year, and I sincerely hope that everyone is enjoying this holiday season...

As I take time off with my family, one thing that I always like to do in some of my spare time is take stock on what I've read throughout the year, to reflect on what I've read and how these books have influenced my thinking. A few of the books I read this year are actually re-reads, like The Goal (I read this a number of years ago, but it's still a great book and very applicable today).

It's always great to read books because you benefit from the experiences and perspectives of others. There isn't enough time in one lifetime to accumulate the information and wisdom that you can get from books. Granted, you need to supplement your own thinking and experience things for yourself, but I certainly like to be informed and have some things in my back pocket to try. It can save you a lot of wasted time and aggravation.

Here's my list of the business books that I read in 2012, in no particular order:

Happy Holidays!

Photo courtesy of Dawn at Flickr.com

Initiate Change, but Don’t Drive It

noreply@blogger.com (Dave Moran) — Wed, 19 Dec 2012 11:30:00 +0000

I’ve recently been examining culture and how agile experiences can be very new experiences for many organizations. On a personal level it is all too easy to adopt the attitude that change is for “the other person” (or department, or division…). When it comes to organizational change, persistent effort over time coupled with consistency is required so that change is not viewed as another management “the flavor of the month.”

You can begin an agile adoption as “something the development teams do,” but as their understanding of agile deepens and their proficiency increases, there will be an increasing need for the rest of the organization to transform to agile. Without this transformation, your agile adoption will either be a watered down agile implementation (sorry, I couldn’t resist the bad pun) or continually at risk of being pulled back to old ways of thinking and working.

In order for lasting change to occur, we must be open to having new experiences, willing to reflect on how our current mental models just might be filled with assumptions rather than facts. We have to be willing to change what we believe. This is why I feel that it is important to initiate change instead of driving change.

Driving change is problematic because people tend to resist being changed by others. People don’t react well when change is imposed. They need to be invited into the conversation about the need for change, what the change looks like and why the change is beneficial. And they most likely will need to make changes slowly, a little at a time.

This allows people the time required to assess their beliefs – their mental models of what they believe works and why it works. Initiating change is an approach of facilitating and guiding change. There needs to be a shared understanding of the current reality and where the organization – fueled by its people – needs to go and how it wants to go about getting there.

If you make the shift to being a true learning organization, one that supports continuous improvement, change can be one step at a time and yet still be – as paradoxically as it sounds – swift. Toyota does two things that are vitally important:

Management is not to focused exclusively on improvement, but on increasing the improvement capability of people.
Toyota makes use of a Plan-Do-Check-Act (PDCA) model, teaching its people to change only one thing at a time.

Toyota wants its people to develop a deeper understanding of the work processes, to have the understanding, capability and initiative to continuously improve. People at Toyota change one thing and then check the result of that change against the expected (planned) result.

The key to rapid change is the execution speed of the PDCA cycle. You need to check the results as soon as possible. Waiting for a formal review cycle that is weeks or months away delays the process. You can read more about this in a book review post on the Toyota Kata.

Do you need to focus on what the organization does right or what it does wrong? The answer to this question is provided in another post, Changing Mindsets: One Key to Successful Organizational Change. This post also outlines four levers of an influence model that can help to shift employee mindsets on a wide scale.

Another ideal component of change is that there is a shared vision that captures the hearts and imagination of everyone in the organization; it should provide people with a higher purpose to collectively pursue. This engages the emotions of both your customers and the people in the organization; you can read more about this in my post, Are People Buying What You’re Selling?

As the organization as a whole adopts change, people need to understand and reinforce behaviors and actions that are in alignment with the new change and constructively challenge one another when old habits and behaviors surface. As part of this, openness and the ability inquire about the thinking of others is essential. We need to have the ability to respectfully explore the actions of others, either to learn how they applied new thinking to an old situation (to learn from them) or to understand why they seem to be falling back into old behaviors – perhaps they are being overwhelmed by competing demands and could use some help.

Don’t drive change down people’s throats, and don’t create artificial crises to drive change, either. That is disingenuous and completely unnecessary in today’s turbulent world. Initiate change by engaging people in the change, then support and reinforce the change.

I’ll close with a quote from the Chinese Philosopher Lao Tzu:

Of the best rulers, The people only know that they exist; the next best they love and praise the next they fear; and the next they revile. When they do not command the people's faith, some will lose faith in them, and then they resort to oaths! But of the best when their task is accomplished, their work done, the people all remark, "We have done it ourselves." (Emphasis mine)

Simple Advice that Saves Time and Avoids Frustration

noreply@blogger.com (Dave Moran) — Wed, 12 Dec 2012 11:30:00 +0000

And it is pretty simple: Shut up and listen!

In my last post on Three Simple Questions That Foster Great Collaboration, I stated that immediately after asking one of those three questions, it was important to listen. The part about shutting up was implicit. However, I found a great TED Talk by Ernesto Sirolli titled,Want to help someone? Shut up and listen! that drives the point home.

Sirolli starts his talk with a humorous story on his well-intended, but misguided efforts he experienced in his youth to bring aid to Africa, teaching Zambian people how to grow food in what he and his compatriots found to be a very fertile valley. They were mystified that the local people had no interest in agriculture – to the point where they resorted to paying them. And even then the locals weren’t interested in showing up.

Why was such disinterest displayed by people for something that was clearly for their own good? The reason became abundantly clear one night – just as the crops had grown out perfectly and changing the, “Thank God we're here!” attitude of Sirolli and his group to one of surprise and leading them to ask, “Why didn’t you tell us?” (Watch the video to find out what happened.)

This became Ernesto Sirolli’s big lesson in listening. And he took that lesson and invented a system he calls Enterprise Facilitation. This system is all about finding out what the other person wants to do. You become a servant and find out what the other person wants to do, what they are passionate about, and then help them down that path.

Sirolli’s talk branches into working with entrepreneurs, and he offers the following secret about working with them: ”First, you have to offer them confidentiality. Otherwise they don't come and talk to you. Then you have to offer them absolute, dedicated, passionate service to them.”

Ernesto Sirolli: Want to help someone? Shut up and listen!

What Sirolli is talking about is simple enough to understand, but often implemented poorly: listening to the market – your potential customers – and serving their needs. After all, a business exists to help others, to provide products or services in exchange for money. You have to provide something of value to another person; if you don’t have enough perceived value for a broad audience, then you don’t have a viable business.

The challenge is in how to go about developing and refining your products and services – before you run out of money. Instead of making BIG BETS, it is possible to make a series of small, quick bets and discover the real truth about whether an idea or concept will work in the marketplace. I wrote about this in a post last year titled, How to Fire a Business Bullet. At its core, it all comes down to listening.

Listening will by large dividends, but all too often it is an underused tool in relationships and business (and business is really about relationships). If you really want to help someone, genuinely listening can save a lot of time and frustration!

Three Simple Questions That Foster Great Collaboration

noreply@blogger.com (Dave Moran) — Wed, 05 Dec 2012 11:30:00 +0000

Agile development is a highly collaborative approach, both in terms of developing of the software and in reflecting on what is working and what needs improvement. And because software development also involves decision-making every step of the way (from the requirements and their prioritization to systems architecture to detailed implementation in code to tools to testing, and so on...), anyone involved with agile teams needs great interaction skills in order for teams to be great.

We need the ability to question and explore another person’s thinking, to raise issues or concerns about the team’s direction, and to constructively challenge each others’ thinking. We need the ability to have an open, honest dialog where people feel respected and safe.

High-performing teams don’t get to a high-performance state through avoidance. Nor can we get to a good place if our exploration puts people on the defensive. We need respectful inquiry that is depersonalized; and this best accomplished through structured interactions.[1]

Sprint planning is a structured interaction. A team retrospective is a structured interaction. In a collaborative environment. Structured interactions – each one having a specific, defined purpose – creates a safe place for people to operate in because the goal and ground rules are established. The next step is to get people to open up.

You must be sincerely interested in what others have to say, to understand what is on their mind, to have a dialog and not a monologue. If you really want to know what people think in ways that keep the dialog going, here are three simple questions to ask:[2]

What do you think?
Why do you think that?
What would you do?

The next, very important step is to listen! Demonstrate that you value what the other person is saying and that you aren’t leaving things open to misinterpretation by employing the active listening technique.

What about your own opinions? What if you’ve researched something in depth and feel quite confident that you are right? Well, you can present your thoughts and back them, absolutely. And you could very well be right, from your perspective. But perhaps someone else has a different take on an issue based on their own understanding and experience. All you need to do here is avoid being anchored by your own opinion.

[1] The Culture Game: Tools for the Agile Manager

[2] Change the Culture, Change the Game: The Breakthrough Strategy for Energizing Your Organization and Creating Accountability for Results