Start Being Agile Today!

Guest post from Dave Moran, founder and agile coach at Agile Guide in Portland, ME

There is a difference between doing agile, which relates to adopting practices and techniques, and being agile, which relates to the mindset and behaviors we use as we leverage agile practices and techniques. This is why agile isn’t a silver bullet process or practice change (or a pill that you can take to alleviate all of your ills), but something deeper and more involved, which comes from embracing the values and principles found in The Manifesto for Agile Development.

These values and principles are expressed as a set of interrelated qualities:


As I see it, agility is realized in different ways at personal, team, and organizational levels. Each one ideally reinforces the other and shares the same values and principles, but the traits and behaviors will be different at each level. Let’s take a look at an example involving learning and continuous improvement to illustrate my point.

For any learning and change to take place you need qualities such as curiosity and a willingness to experiment. You need to support the notion of continuous improvement and that your own qualities (and those of your team) are things that can be nurtured and cultivated.

At a team level, we need these core qualities and more. We need the willingness and ability to use respectful interactions. We need to have the desire, courage, willingness and ability to reflect on our current situation, examine habits, behaviors, structures and policies in constructive ways with our teammates. And just as it is at a personal level, the team as a whole needs to be willing to experiment with new ideas in order to improve.

Learning must be also supported at the organizational level. Does your organization mandate a specific approach and “best” practices? (Personal opinion: Don’t use the word best. What is “best” in an environment of continuous improvement?) Can teams experiment and choose to stop doing some things and start doing others on their own, without having to seek permission and/or jump through hoops to obtain that permission? Are there mechanisms to easily share information and learning across the organization?

Each, as I said, ideally each reinforces and supports the other. But that isn’t always the case. An often-cited example is where an agile team is injected in the middle of a non-agile organization: there will be a lot of challenges since there will be a lot of organizational “pull” back toward non-agile behaviors and ways of operating.

I’m sure you can readily see that it is advantageous to have a reinforcing cycle. Awareness of these levels can also help you see how conflicting values can come into play that cause stress and anxiety on the job. If you have a strong desire to work in ways that are more in alignment with agile values and principles, for example, but your organization is a strong hierarchical, command-and-control organization, you will feel conflicted.

For those of you working in companies that haven’t gone down that agile path yet, but are wishing for it, the good news is that you don’t have to wait. At the heart of it all are people. People comprise teams and organizations. This is where personal agility comes into the picture. And while it is helpful to have greater support from your immediate team or organization to be agile, you don’t have to be part of a Scrum team or have your organization endorse agility for you as an individual to begin walking down the transformational road!

Personal agility is not a role, like being a ScrumMaster. Positions or roles in and of themselves don’t make you agile. Being a certified ScrumMaster doesn’t quite get you there, either. It’s a step in the right direction, though. Certification qualifies that an individual has undergone training and knows the Scrum framework. It prepares you to do agile as a team, providing a framework from which to work that supports being agile.

Personal agility is all about the qualities that you bring to the table. These qualities relate to the approach, values and behaviors an individual brings to a role. This is why there can be differences in how ScrumMasters guide their teams, just as there are differences in how project managers direct their teams.

As you read through the key qualities of personal agility below, ask yourself if you are strong or weak in any of these areas, and what you can do today to start making meaningful changes:

Improvement/growth oriented: Seeks opportunities for growth and is willing to work outside of his or her comfort zone, possessing what Dr. Carol Dweck calls a growth mindset. Open to accurate information about current abilities in order to genuinely improve.

Courage and reflectiveness: It takes courage to accept feedback and to be open and honest about yourself and where you are today so that you can accurately reflect on what is working and what needs improvement.

Positive attitude and approach: Does not view setbacks as failures, but as opportunities to learn. Recognizes that we are able to access more competencies and be more productive when we are in a positive state of mind than a negative one, allowing us to find solutions to difficult problems or situations.

Curiosity and a questioning mind: Is inquisitive and has a passion to learn more about his or her profession. Questions such as, “How can we simplify? How can we do better?” “What if…?” are always being asked. This also includes a willingness to speak up and engage others in questioning the status quo.

Self-discipline: Motivates himself/herself to do what is needed.

Willingness and ability to handle ambiguity: Recognizes that complex situations contain variability and uncertainty that can be successfully navigated.

Adaptability: Able to work outside of prescribed process/role/specialty; willing to develop T-shaped skills and is open and receptive to new situations and different perspectives.

Takes responsibility and owns the results: Is equally concerned with what gets done and how it is accomplished. Focused on solid execution, but takes the time to understand the big picture.

Builds trust and develops relationships: Listens to others without judging, probing and asking questions to understand and engage others in ways that make them feel safe. Invests time and energy in creating stronger, trusting relationships that create frequent, authentic, high-bandwidth lines of communication  essential in a collaborative culture.

Willingness to experiment: Takes the initiative to execute a lot of little experiments (implementing new practices or approaches) designed to generate information to learn from and improve performance.

Can tools and practices help? Absolutely. I’ve been making use of Personal Kanban to organize and balance my professional and personal aspects of my life. I like visualizing my work and making sure that I’m not keeping myself too busy with day-to-day firefighting and ignoring my long-term goals and objectives. Like an agile team, I rigorously prioritize my backlog.

But in the long run, it’s the approach, traits, and behaviors – your mindset – that makes the greatest difference. However, no one can make you be agile, nor can they talk you into it if you don’t see any value in changing. I’ll close with two questions: Do you see value in being agile? Are you willing to walk down that road?

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Methodologies, Agile Teams, Agile Tools, Kanban | 2 Comments

Reasons to Check Out Agile Open Northwest

Imagine entering a bazaar where all your questions are answered by experts with wide ranging perspective, beliefs and experiences.

Think of being transformed by the learnings, exchanges, debates and discussions.

Visualize being feeling courageous, bold and spontaneous when new topics are introduced or new practices are shared.AON-2014-logo

This defines the Open Space experience.

If you’ve never been part of an Open Space, I’d like to invite you to break the ice at Agile Open Northwest from February 5th – 7th in Seattle, Washington.

Been around Open Space before? Then this event’s for you. You’ll fit right in amongst some of the sharpest and brightest minds from the Pacific Northwest. This year’s event, titled “Agile – Harder Than It Looks,” brings you face to face with some of the toughest challenges facing your teams and organizations.

Here are just a few of the questions that might be tossed, turned and flipped outside down over the course of the 3-day event:

  • What is the difference between Lean, Scrum, XP and other agile approaches?
  • What new technical challenges face agile professionals?
  • What are the latest cutting-edge developments in the agile software development world?
  • How do agile frameworks and methods co-exist with project management, process control and other governance structures?

VersionOne is a proud sponsor of this event; we are thrilled to once again support the passionate agile community of the Pacific Northwest.

The event is sold out (not a surprise!), but place your name on the wait list for a possible chance to score a ticket.

Thank you Agile Open Northwest for giving VersionOne a wonderful outlet to connect with the Agile community. Pacific Northwest Agile community: you are fortunate to have this opportunity again for 2014.

Don’t miss Agile Open Northwest.

Dan Naden
Community Marketing Manager

Posted in Agile Methodologies, Lean, Scrum Development | Leave a comment

The Agile Coach on Courage

The Scrum team’s way of working is based upon the values of Focus, Openness, Commitment, Respect (for self and others) and Courage.

For this blog post, I’m going to dive into that last value a bit more because I think it often gets overlooked… courage.

Image credit: Cottage 960

What does this really mean? How can someone in IT be courageous? That’s just for folks in the military, firefighters or police officers, you might say.

Not so, I say.

A few scenarios might help.

Scenario 1 – I’m the Product Owner for a mission-critical agile project. The CEO of the company comes directly to me and says he wants the team to add another feature into our current Sprint. Says he needs it ‘ASAP.’ This feature is useful and needed. It makes sense to do it, but it’s not a small demand. The team is making good progress on the current sprint and only has 4 more workdays before they deliver the agreed upon functionality for the 2-week sprint.  Would you simply say ‘Yes’ because he’s the CEO, or would you delve a bit deeper into the current status of the project/sprint and the priority of your Product & Release Backlogs, explaining to him that stopping a sprint-in-progress could have a larger impact, and what that might be? Clearly, this takes courage.

Scenario 2 – I’m the Manager of the newly created Agile PMO. I report directly to the VP of IT. She’s a reports junkie; she likes to see a lot of ‘em, and at many different levels. She also likes to have me deliver these reports verbally and via email to several different groups of folks in the organization. She changes her mind a lot on what she wants to see, too. I spend an inordinate amount of time doing this reporting and delivery, which I believe should not take up this much of my time every week. I have many other important items to tend to, as the organization is in the midst of an agile adoption and transformation effort. Do I have the courage to set up a conversation with her and explore her motives, exploring new ways of disseminating information, explaining the impact this current situation is having on my many other demands? This takes courage.

Scenario 3 – I’m a Team Member on an agile team. My forte is writing Java code. But I can do almost anything, or at least am willing to try/learn. If I finish up the tasks I signed up for in the current sprint, I ask around if anyone on the team needs help. If not, I get coffee, or give shoulder massages. But there’s one individual on the team who doesn’t have the same ‘All for one and one for all’ attitude that the rest of us do. Oftentimes, during the Daily Stand-Up meeting, he’ll report that he’s ‘got nothing,’ and looks to move on to the next person to answer his 3 questions. He doesn’t ask if he can help or learn how to do something; he doesn’t appear to be a team player. Do I have the courage to go to him and ask what’s wrong, or how I can help? And if that doesn’t work, do I have the courage to suggest that we remove him from the team?

And a few more questions of courage you could ask yourself…

Do I have the courage to try something completely outside of my comfort level?
Do I have the courage to be completely open?
Do I have the courage to throw away bad code I created, even late in development?
Do I have the courage to allow my direct reports to ‘self-organize?’
Do I have the courage to become less command-and-control and more collaborative?
Do I have the courage to give up my cubicle, and a bit of my privacy?
Do I have the courage to say I’m scared how this new way of working will impact me?
Do I have the courage to ask for help from someone junior to me?

What are some of the more courageous things you’ve done at work, and what impact did they have?

Posted in Agile Adoption, Agile Management, Agile Teams | 3 Comments

The Agile Coach on Enterprise Agile

I recently spent a full day at a Fortune 500 company consulting their Agile Center of Excellence and later presenting to a larger group of Executives. I actively listened to what they told me about their organization, their successes and struggles with Agile. They asked lots of questions about how I’d done things in past Agile engagements, including Agile at the Enterprise level. All in all, a very rewarding experience.

But it was the topic of scaling Agile that seemed to garner the most interest.

Image credit:
I think many organizations have been attempting Agile at the Enterprise level for a while now, but maybe not doing it in the most efficient and effective way possible. There’s clearly real opportunity in this area. Overall, companies appear to be doing great on the Project (Team) side, but struggling at the Program and Portfolio level. In order to link our overall strategic vision with projects, and coordinate those projects across teams, we must be effective at this. It’s vital to the success of any organization.

Enter Dean Leffingwell, creator of SAFe (Scaled Agile Framework). His framework and accompanying certification program is all the rage in Agile circles today. I believe folks have been looking for someone to put a formal framework (and catchy tag) to this for a while now. And to Leffingwell’s credit, he has done a good job of that with SAFe. Check it out at

While Leffingwell labels SAFe as a framework, some of the folks I’ve talked with and various blogs I’ve read see it as more prescriptive (a methodology). And while thorough, some are suggesting it may be a bit too complex.

But maybe that’s what folks want right now; something that tells them exactly what to do, when to do it, who does it, regardless of its complexity. In fact, I see some new teams that approach Scrum like that. Even though it was created as a framework, they treat it like a set of standards and procedures that must be followed to the tee.

So let’s consider how organizations accomplish their goals and reach their strategic vision in an Enterprise. Call it Scaled Agile, or call it Enterprise Agile. I’ll use the latter term for simplicity.

There are three levels necessary to successfully implement Enterprise Agile; the Portfolio, the Program, and the Project.

At the Portfolio management level, we’re deciding if we’re making the right investments that will allow us to realize our strategy and vision. You may have at least one and possibly several Programs within a Portfolio.

At the Program management level, we’re managing resources and deliverables. Our job is to drive the execution of the decisions made by Portfolio Management. This requires we communicate constantly with them, so they’re always aware of any changes (e.g. how dates might be affected.)

At the Project management level, we’re getting the most granular level of work done. Part of our job is also to deliver status to the Program.

In short, all three levels must share information and communicate constantly. What we don’t want to happen is for any of these layers to get silo’d. Enterprise Agile simply won’t work effectively if they do. We need a holistic approach that helps us to deliver to our customers what they want and need. Based on some of my experiences, this is exactly where a lot of organizations fail with Agile.

As for the nuts and bolts details of how to accomplish Enterprise Agile in an Agile software management tool, check out how VersionOne does it. This video walks you through it step by step, simply and elegantly.

How are you scaling Agile in your enterprise? What are your challenges?

Posted in Agile Management, Agile Methodologies, Agile Project Management, Scaling Agile, Uncategorized | 1 Comment

Balancing Individual Focused Work with Collaborative Team Work: Open-Office Bullpens are Harmful!

Agile teams require effective cross-functional, self-organized teams.  Effective collaboration and team work are also important.   To facilitate teamwork and face-to-face communication and collaboration, management thinks open-plan office is the way to go.  Businesses of all types have moved towards sitting workers in groups in open-plan rooms.  Of course, open-plan offices were becoming common well before the Agile Manifesto of 2001.

But in the head-long rush to open-space kumbayah, many agile teams are thrust into one or more open-plan office bullpens.      Open space communication has costs as well as benefits. These need to be considered carefully.  Do not assume that the more unfettered communications among team members, the better the teamwork.  It is time to question the faith in all things open-plan as evidence is mounting that this is a bad idea.


Open-Plan Office bullpen: Image Credit: Veronica Therese, Wikimedia Commons

Two influential no-nonsense business newspapers, The Wall Street Journal and The Economist, have done just that.    Schumpeter’s article in the 7 Sept 2013 edition of The Economist reports the following key points:

  • According to one survey around 70% of all offices in America have gone open-plan.
  • Open-plan offices make it more difficult to concentrate, because the hubbub of human and electronic noise is distracting.
  • Workers really value the ability to focus on their jobs with as few distractions as possible.
  • Ironically, open-plan office prevents workers from collaborating, because they cannot talk without disturbing others or inviting an audience.
  • Too much reliance on teamwork can create a culture of “learned helplessness” in which decisions have to wait until yet another round of consultations.
  • Excessive collaboration can lead to the very opposite of creativity: groupthink, conformity and mediocrity.
  • People who work in open-plan offices are more likely to suffer from high blood pressure, stress and airborne infections such as flu.

The article concludes by stating that managers should treat collaboration and creativity as techniques rather than dogmas.  The article suggests that it is time for separate, individual offices.

Sue Shellenbarger reports in her well-researched article in The Wall Street Journal of 10 September 2013 that open-plan offices bring an unintended downside: pesky, productivity-sapping interruptions. The most common disruptions come from co-workers. Face-to-face interruptions from co-workers account for one-third more intrusions (which are difficult to avoid) than email or phone calls (which can be deferred or ignored).  Frequent interruptions lead to higher rates of exhaustion, stress-induced ailments and a doubling of error rates.  The WSJ article reports several key findings:

  • An interrupt of even 2 seconds is long enough for people to lose the thread of a difficult or complex task
  • Average time spent on a task before being interrupted: 12 min 40 secs
  • Average time elapsed before returning to work on the same task: 25 min 26 secs
  • Average time required, after resuming a difficult task, to get back into the same level of intense concentration: 15 min
  • Percentage of tasks that are interrupted when people work in open-plan offices: 63%
  • Percentage of tasks interrupted when people work in private offices: 49%

The WSJ article summarizes a range of compensating behaviors to handle interrupts as recommended by many experts:

  • Use “do-not-disturb” signals like wearing hats or armbands, stretching barricade tape around their cubicles, and wearing yellow slashes across shoulders.
  • Interrupt others only when a problem is of very high priority. For less-important matters, send a meeting request.
  • Break the habit of jumping up to talk to a colleague any time a question comes up. Instead, keep a separate “talk-to” list of topics for each colleague, then wait until you have several items and schedule a meeting.
  • Ask an interrupter to wait while you record your last thought on a sticky note and post the note on the page or screen to mark where you stopped working. The visual cue can cut the time needed to restart a task by as much as 80%.
  • Tell your interrupter that you will meet him a few minutes later in his own office or cube. That lets you complete the task you are working on, and take control over the length of the meeting. Not only can you do it on your schedule, but you can leave when you want to.
  • Minimize unscheduled meetings.
  • Download a free “Interrupters’ Log Worksheet” from to help analyze the sources of interruptions and either eliminate or minimize them.

In my experience, agile team members are involved in two very different types of activities:

  • Intense, focused personal work:  Design, code development, unit testing, defect debugging and fixing, writing (automated) unit tests and acceptance tests, refactoring, etc.
  • Collaborative team work: story writing, planning, design review, code review, test review, technical discussions among team members, Daily Scrums, Sprit reviews, Sprint retrospectives, Release retrospectives, etc.

Depending on organizations, projects and team dynamics, in my experience typically 75% work is intense-focused personal work, and 25% work needs interactions, communication and collaboration among team members.   Companies with agile projects need to rethink their office space layouts and policies governing office space use.  As the work is more on the side of intense focused individual work (approx. 75% as I suspect) supplemented by collaborative team work (approx. 25%), it behooves to consider:

  • Private individual offices with closed doors: each office may be small (8’ x 8’), with a window (as much as possible) where intense, focused individual work is carried out without interruptions from others.
  • Team rooms for team-level interactions and collaboration: Story writing, Release and sprint planning, Planning Poker and estimation, Daily Scrums, Sprit review, Sprint retrospectives, Release retrospectives, etc.  Team rooms must have projector, whiteboard, flipchart, and network connections.
  • Break-out collaboration rooms: They are for smaller subgroups, typically 2 to 4 members, for intense technical discussions, design reviews, code reviews, test case reviews, pair-wise programming, etc.  Some of these activities can be carried out in individual offices so long as a fairly small number of people are involved.  For developers to do collaborative work, some of these break-out rooms may need to be fitted with a large pair of monitors and network connection.


Team Room at VersionOne

This sort of office plan and company policy will go a long way in providing the right balance between intense focused individual work and team-level collaboration.  When individuals move to a team room or a break-out room with their laptop PCs, they should be able to do all work that can be done in their individual offices.    This new office space plan will not be a panacea or nirvana, though.   By itself, it will not eliminate or minimize the dangers of multiplexing or multitasking.  I have explained in my blog In Praise of Master-of-One-Jack-of-Two how to deal with the evil of multiplexing and multitasking.  Inside an individual office, unlike an office bullpen, you may not be distracted by colleagues, but you could still be tempted by your web surfing habit, and you may immediately respond to endless streams of e-mails, instant messages, chats, phone calls, RSS feeds and tweets.   Those “intrinsic” interruptions can be dealt only with self-discipline, which will be a topic of my future blog.

So why many agile teams are crammed into common office bullpens, you may ask.  Part of the reason is the dogmatic adherence to unfettered communication and “teamwork” that is supposed to come naturally with open-plan office space kumbayah.  The other part is undoubtedly driven by cost considerations.  It is less expensive to cram a large number of people in bullpens instead of giving them individual offices. However, this is true only for the office space cost.  But if you factor in the costs incurred by lost productivity in noisy bullpens, lower morale, higher stress and fatigue, more errors and rework, lower quality, higher attrition rate among talented employees, and more difficulties in recruiting new talent, I am not sure how much cost advantage of bullpens would still be there.

In my over 30 years of professional career, I have worked in companies with private individual offices (supplemented with team rooms and break-out rooms), bullpen-only environments (with few conference rooms), and bullpens supplemented with team rooms and break-out rooms.   I can unequivocally say that the private individual offices supplemented with team rooms and break-out rooms offer the best balance between intense individual focused work and collaborative team work.

What about serendipitous, impromptu, ad hoc communication that often are claimed to increase inter-personal interactions and shared context required for high-performance teams?  There is some merit in this claim.  It would be an extreme position to insist that all face-to-face or real-time or in-person communication must be via scheduled meetings.  There is a place and need for proverbial water-cooler discussions, brown bag luncheon meetings and presentations, unplanned discussions during coffee breaks and in food lounges at offices.  I advise my clients that each team member may post 3 to 4 time slots in a week (say 30 minutes each) for open-door discussions, where others may interrupt them without permission or pre-scheduled meetings.  During these time slots, a member can take care of low-priority tasks where intense focus is not required, such as filing expense statements, trip reports, or e-mails that can be quickly answered in 2 minute responses.  If someone stops by to discuss any issue, both members should go to a break-out area to discuss if they work in an open-plan environment to avoid disturbing other coworkers in their bullpen.  Even if agile teams in an organization need to spend 50% of time for face-to-face communication, open-plan office bullpens are the wrong place to do so.  Those team members need to go to team rooms or break-out rooms for face-to-face communication to avoid disrupting others in the bullpen.

As The Economist and WSJ articles suggest, don’t you think it’s time to get away from office bullpens and move into individual offices supplemented with team rooms and break-out rooms?

I would love to hear from you either here or by e-mail ( or hit me on twitter (@smthatte).

Posted in Agile Management, Agile Methodologies, Agile Teams | 5 Comments

Best Agile Management Blog Posts of 2013

It’s a busy week. Many of us are returning ugly sweaters from Great-Aunt Lenora, re-gifting fruit cakes, and putting away holiday decorations (DON’T be that house with a reindeer globe on the lawn in February). Just be glad you’re not working the customer service counter at WalWorld today!

Take a little break from the hustle… complements of another group who has been very busy this year: the VersionOne Agile Coaches. They’ve managed to write 98 blog posts on a variety of agile management topics to help people kick ass at what they do.

I thought I’d ring in the New Year by highlighting the 10 most popular ones:

1. Re-Imagining the Agile Manifesto by Brian Watson.

In this post Brian suggests that we re-imagine the Agile Manifesto as a set of guiding principles vs. some iron-clad document.

2. 12 Awesome Interactive Facilitation Techniques for Agile Teams by Matt Badgley.

If you work with a team (possibly as the ScrumMaster, Lead or Product Owner, or just a Team Member trying to guide a conversation), then these interactive facilitation techniques are for you.

3. The Agile Coach on ‘Individuals and Interactions Over Processes and Tools’ by Mike McLaughlin

With agile software management tools becoming more and more prevalent in organizations, are we getting away from the importance on ‘individuals and interactions’? Interesting topic, coming from a company that builds and sells agile project management software!

4. Words Mean Things: Waterfall Project Management by Matt Badgley.

In the world in which we all live today, it’s very likely that we’ll have a mix of projects using a more of an agile approach and one using more of a waterfall project management (or Sequential approach, as Matt calls it). Sometimes we’ll have to join forces and combine the output of these approaches into one.

5. Agile “Engineering” Practices: A Cheat Sheet by Steve Ropa

Every once in a while, somebody posts an article about “The Agile Engineering Practices,” usually why we shouldn’t do them, or why they are considered “harmful.” Someone often follows up either rebutting or commenting that the original author clearly didn’t understand Engineering Practices in the first place. So Steve has create a little cheat sheet as to what he believes these practices mean.

6. Making Release Retrospectives Strategic and Effective by Satish Thatte

Here you’ll learn in detail how to: (a) define strategic objectives and associated strategic metrics; (b) conduct periodic measurements to collect data to support the strategic metric; (c) use release retrospectives to analyze the strategic metric data – and likely causes for the issues revealed by the metric; and (d) develop and implement an action plan.

7. 5 Simple Guidelines to Agile Metrics Bliss by Matt Badgley.

Matt explored some of the “don’ts” — and more importantly, explains his top 5 “do’s” of agile metrics and reporting.

8. Reject the Tyranny of Metrics by Steve Ropa.

Are agile metrics truly necessary? If so, what agile metrics are helpful rather than dangerous?

9. Where Art Thou, Product Owner? by Brian Watson

Regardless of which ‘Church of Agile’ you worship, there is one constant that cannot be overlooked:  the value of the product owner. Collectively, Brian says we need to ensure that a lack of strong product ownership does not sink the agile ship.

10. Scalable Agile Estimation and Normalization of Story Points: 5-Part Series, by Satish Thatte.

A detailed review of the key assumptions that must be satisfied for traditional, velocity-based planning to work properly. Satish presents 3 specific challenges associated with traditional velocity-based planning, and what happens to those challenges as agile projects need to scale up. He then critiques 2 existing scalable agile estimation methods and presents a scalable method called Calibrated Normalization Method (CNM). Finally, Satish explains how CNM performs the top-down estimation (from portfolios to programs down to teams).

Posted in Agile Coaching, Agile Development, Agile Management, Agile Metrics, Agile Teams, Enterprise Agile, Scaling Agile, Scrum Methodology, Scrum Software | Leave a comment

Agile for the Knowledge Age

KnowledgeOne of the greatest ironies in business today is found in our management practices.  Recruitment is estimated to cost nearly 150% of the first year’s salary for the new hire.  This comes as no surprise, since companies want the best to work for them.  So, they spend all this time and money searching, interviewing and lunching people until they find the “right fit”, the brightest minds, the ones who will really make a difference, and when they’re finally fortunate enough to land them, they put them in a chair and tell them exactly what to do and how to do it… Huh!?!?

Now, if you believe in crystal balls, that people are resources, or you still find yourself thinking in terms of carrots and sticks, then the above statement may not seem like much of an irony at all. For the rest of us, however, it’s confounding and can often be a great sucking force on the gratification we seek to find in the work we do.  But, if it’s so obviously wrong, then how did we even get to this point? Two words: Industrial Revolution.

Industrial Age

In the late 18th and early 19th centuries, new manufacturing processes, mainly in the form of machines, changed the way products were made.  Machines, which are made up of intricate and precise parts that are designed to work together, were found to produce their products in a much more efficient and effective manner than had previously been achieved.  While this became a boon for much of the world’s economies, machines still needed people to create, run and maintain them.  This factor inevitably changed the way people worked.

Think about it this way, if machines were so effective and efficient, then why couldn’t people be made to work the same way and have a similar level of productivity?  Genius, right!?  Well, in fact, it was.  People were trained to perform very specific tasks and they began to be managed under very detailed, and sometimes complicated, structures.  People became an extension of the machines they were meant to create, run, and maintain, while managers were needed in order to get people trained and running the way they were designed to work.

This worked very well when it came to rudimentary and easily repeatable tasks, which most jobs required at that time.  One problem with this, however, is that, unlike machines, people have brains.  And, if you are going to argue that machines have started to have brains too, don’t forget the most important difference between people and machines; the human spirit.

Brains + Spirit = Dreams; Enter the Knowledge Age

One could argue that people have always had dreams, and I believe this is true.  The problem is, before the Industrial Age, no one had time to realize them since they were doing everything they could just to survive.  Since then, we can easily see how so many dreams have been and continue to be realized; electricity, telephone, motorized vehicles, airplanes, nuclear, wind and solar energy, space travel, household appliances… oh yeah, and computers.  Each of these innovations spawned more innovation; people started to realize that dreams could become reality, and that left no limit to what could be done.

So, how do we draw a line between the Industrial Age and the Knowledge age?  In a post titled The Knowledge Age, on the Shifting to 21st Century Thinking in education and learning website, the author states, “Knowledge Age knowledge is defined—and valued—not for what it is, but for what it can do. It is produced, not by individual experts, but by ‘collectivizing intelligence’ – that is, groups of people with complementary expertise who collaborate for specific purposes. “

I think of it like this: Industrial Age knowledge was contained or siloed by very specific people.  In organizations, management likely had the knowledge needed to solve problems and it was rarely shared with the common worker.  In the Knowledge Age, knowledge is open and free for anyone to have.  This “collectivized” knowledge not only frees others to realize their dreams, but also arms them with the information on how to do it. Instead of a limited group of people and organizations owning this knowledge, now anyone is capable of great innovation, which gets us back to the heart of this post; how we manage the people we hire.

The only constant in life is change – Heraclitus

Now that knowledge is so abundant, we need to consider what impact that has on the way we do business.  Look at how technology has affected all aspects of our lives; it has become an integral part of everything we do.  This fact, coupled with the continued reduction in the cost of technology, brings on a level of change we have not before seen.  Change happens so fast, in fact, that large organizations are struggling to maintain their competitive edge due to their very detailed and sometimes complicated (bureaucratic) structures.  In a world where anyone can build innovative creations and reach customers across the globe, it is imperative that any organization, who wants to maintain a competitive edge, have the ability to quickly respond to change.

Dr. Stephen R. Covey, author of The Seven Habits of Highly Effective People, said on his site in a Q&A session that, “in the Knowledge Age, change, not stability, is a given.”  If change is given, then how do we manage people to be able to respond quickly?  It’s a trick question, because the answer is that we don’t.

In his book, The 8th Habit, Dr. Covey states that he believes the Knowledge age will out produce the Industrial age by fifty times.  When asked in this same Q&A why he’s so confident in this increase in productivity, he states the following:

Simply because people are empowered; and not only people, but entire cultures. These cultures will experience an internalization of the idea of interdependency so that the mores and norms are supportive of being productive and everyone will be accountable to everybody. This will unleash incredible energy, talent, creativity, resourcefulness, and new ideas. If I could have people understand one key paradigm of the Knowledge Worker Age it would be that you manage things, but you lead people. That is how we will empower them. (Italics and bold added for emphasis.)

Agile in the Knowledge Age

There is a movement in the software development industry, called Agile, which holds to principles and values that are focused on being able to adapt to change.  At their core, these tenets are centered on people, and instead of telling people exactly what to do in an Industrial Age manner, leaders are told they should empower their employees to make decisions in a self-organizing, highly accountable environment.  While, at the same time, these same leaders are told they should relinquish their command-and-control style of management and instead become servant-leaders, all in the name of higher productivity and being able to stay competitive.  Sound too good to be true?  Well, according to the Annual State of Agile Dev Survey, conducted by VersionOne, respondents said that, on average, the ability to manage changing priorities increased by 90%, and that productivity got better by 85% when adopting Agile practices from their traditional (Industrial Age) practices.

Just to give you an idea of which companies are adopting Agile practices, Microsoft, Apple, HP, Oracle and Adobe should be some names you can relate with.  And, the adoption is growing beyond just software development as more manufacturing, food, hospitality, government and construction organizations, just to name a few, are starting to adopt the various methods that adhere to the Agile values and principles.

These companies and industries are all recognizing our rapidly changing world as we shift into the Knowledge Age.  They have also recognized that Industrial Age tactics are not going to help them continue to be competitive, and in order to be competitive, they must change their relationship with their customers as well as with the people they employ.  As you move forward in your business, have you considered whether you are still using an Industrial Age style of management?  If you are, do you recognize how that style may hinder your ability to manage change and be productive?  If not, you need to, and if you think your industry is safe from the effects of this rapidly changing environment, you may want to reconsider, because with new innovations like 3D printing, synthetic biology and nanomaterial, you may wake up one morning to a whole new world and not even know what just happened.

Is Agile the answer for our shift to the Knowledge Age?  Right now, it seems to be focused on the right things, and considering the success companies are having in their adoption, it’s at least a step in the right direction.  There is one thing for certain, however, that is that we, as people, are changing.  So, whether your industry or business is feeling the immediate impact of the Knowledge Age, your employees are, so it just may be time to reconsider your management practices nonetheless.

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Teams | 1 Comment

The never ending Christmas list

It’s that time of year when Christmas lists make the rounds of family and friends. This annual rite of passage can usually be summed up as “I want, I want, I want”. Unfortunately in software development, most of our business users do not wait until the holiday season to give us their shopping list; we get their “wants” year ‘round. Think of these requirements lists as the Christmas list that keeps on giving…teams heartburn.

Need Want Like Keys Showing Craving And Desire

Simply calling them “requirements lists” already puts teams at a disadvantage. The word requirement implies that something is needed. The real question should be, are they?

I think if we applied the Pareto principle to “requirements”, we can stop the dreaded bloated project scope. How do you ask? Simple, how many “requirements” does the business offer that are reasonable every day scenarios and how many are obscure exception cases? I bet if you dig into your average 400 page “requirement” document deep enough you will find the majority of the “must have” requirements cover obscure scenarios that happen 1- 3 times a YEAR. While I understand it is important to know what to do if a meteor hits the building, while it is snowing and the coffee pot has stopped working, do we really need to invest in months of development time to account for that?

While that seems like an outlandish example, companies are “requiring” that of their systems every day. Rare, exception paths that occur on such an infrequent basis that only employees who have been around 5 years have even heard of them bloat our systems and delay putting meaningful, useful code into production.

Think about it. What if we only coded the 20% of requirements that meet 80% of the needs, then simply worked with the business to handle those rare exceptions? For starters we would avoid teams crying, “the scope of this project exploded”! Management could stop beating teams up for failing to “control” scope. But most important, the business would get core functionality sooner (and cheaper)!

This isn’t a fantasy world. No one has to ask “If only there was a way…”. We HAVE the way; they are called user stories. While it may be a huge culture change to think of projects in terms of user interactions with a system resulting in value, vs. a nauseating list of “the system shall…” statements, this is the key to avoiding waste. When you elicit and document requirements for user interactions vs an endless universe of possibilities we build smaller, maintainable, scalable systems that the users can actually use.

So, next month when you move away from the Christmas list to that other holiday tradition, the New Years Resolution, please (PLEASE) make leveraging user stories vs. “requirement” lists part of your 2014 goals.sign announcing 'New Year's Resolutions'


Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Methodologies, Agile Software, Agile Testing, Distributed Agile, Extreme Programming, Lean Software Development, Scrum Methodology | 1 Comment

Scalable Agile Estimation and Normalization of Story Points: Calibrated Normalization Method for Top-Down Estimation (Part 5 of 5)

In Part 1 of this multi-part blog series, I introduced the topic of the blog series and provided an overview.  Scalable agile estimation methods are required to provide reliable estimates of workload (work effort) and also reliable velocity metrics (both estimated velocity and observed velocity) at the team, program and portfolio levels of large-scale agile projects.  Without reliable estimates of workload and reliable velocity metrics at all levels, effective and meaningful determination of costs, return on investments and prioritization cannot be made.   For scalable agile estimation methods to work properly, story points across the space dimension (teams, epic hierarchies, feature group hierarchies, goals, project hierarchies, programs, portfolios, etc.) as well as across the time dimension (sprints, release cycles) need to have the same meaning and the same unit of measure.  In other words, story points need to be normalized so they represent the same amount of work across the space and time dimensions.

In Part 2 I reviewed the key requirements that must be satisfied for traditional velocity-based planning to work properly.  I presented three key challenges associated with traditional velocity-based planning, and how they are exacerbated as agile projects begin to scale up.  The three key challenges are:

  1. A single story point is unlikely to represent the same amount of work across teams and sprints.
  2. Bottom-up story point data is frequently not available for estimating work during program and portfolio planning.
  3. Yesterday’s weather model requirements may not hold for one or many of the multiple teams involved in large-scale agile projects.

In Part 3 I presented two published scalable agile estimation methods along with my critique.  The first method is covered by Mike Cohn in his Agile Estimating and Planning book.  The second method is the story point normalization method promoted by SAFe that I refer to as “1 Point = 1 Developer Day Normalization Method” (1NM for short).

In Part 4 I presented a scalable agile estimation method, called Calibrated Normalization Method (CNM).   Part 4 emphasized CNM bottom-up estimation (from teams to programs up to portfolios).  CNM (bottom-up estimation) consists of four steps summarized below.

  1. Decide on the Normalization Basis for an enterprise.
  2. Estimate the relative sizes of stories using relative sizing techniques
  3. Determine the Calibration size for each team.
  4. Normalize the story points and enter NSP for each story in an agile project management tool

CNM is a general method for story point normalization, and is not tied to any specific agile scalability approach or framework.   CNM can be applied to small (even single-team) agile projects, very large agile projects consisting of multiple portfolios and programs, and enterprises with a large number of mostly independent projects.

Before describing how top down estimation works, it is important to recognize the key responsibilities of portfolio management and program management.

Portfolio management responsibilities:

  • Assess, prioritize and select business initiatives to pursue that will create the most value for the company
  • Authorize funding for business initiatives, review the progress to provide governance over funding
  • Select business initiatives with less details, but gain better insight for governance by reviewing demonstrated progress via working software

Program management responsibilities:

  • Coordinate teams and resources in the most efficient manner to deliver on the selected business initiatives
  • Decompose business initiatives to identify specific deliverables and required resources
  • Serves as the glue that links business strategy and initiatives to execution
  • Update the portfolio level with project-level execution that might affect the value from a business initiative

Top-Down Estimation

A key component of CNM is the method for performing top-down estimation (from portfolios to programs down to teams).  CNM estimates the scope of work at the portfolio and program levels without knowing lower-level story point details which are typically not yet available.  For a portfolio, CNM requires identification of a baseline epic, an epic about which the portfolio leadership team has the most knowledge. Similarly, CNM requires identification of a baseline feature in the baseline epic, which is the feature about which the program leadership team has the most knowledge. Finally, CNM requires identification of a baseline story in the baseline feature, which is the story that the program leadership team feels most confident in estimating. Then estimation begins. The baseline story is estimated in normalized story points (NSP). Once the baseline story is estimated, then all other stories in the baseline feature are estimated using relative sizing techniques; then the roll-up of those story estimates become the estimate for the baseline feature. Then other features in the baseline epic can be relative sized against the baseline feature, which then roll up to the baseline epic estimate. Finally, other epics in the portfolio can be relative sized against the baseline epic, which then roll up to the portfolio estimate. All of these estimates roll-up consistently as NSPs.

Clearly these estimates can only be rough as lower-level story point details for all stories are not available; only the story point for baseline story is known along with relative sizes of stories (compared to the baseline story), relative sizes of features (compared to the baseline feature) and relative sizes of epics (compared to the baseline epic).    This information is still more credible and directly tied to the portfolio and programs at hand compared to pulling swags (smart wild-ass guesses) or gut-feel numbers.    These rough estimates done during portfolio planning are later progressively elaborated and revised during program planning and team-level sprint planning as more information becomes available about lower-level story points.

Portfolio and program-level estimates are used to answer two important and legitimate business questions asked by management.

  • For a given set of teams and a fixed amount of time (usually represented in number of sprints and release cycles), estimate the scope of work (represented by planned epics or features).   This is called Fix time/Flex scope planning, which is the most common type of agile planning. From the given set of resources and the fixed amount of time, cost (budget) can be derived.
  • For a given set of teams, and a fixed scope of work represented by planned epics or features, estimate the amount or time (number of sprints and release cycles) required, and estimate the cost that would be incurred to deliver those epics and features.  This is called Fix scope/Flex time planning, which is less common than Fix time/Flex scope planning.

While we have discussed team-level planning in Part 4 of this blog series, in practice an enterprise will typically begin portfolio planning, then proceed to program planning, and finally do team-level planning.

Estimation at the portfolio level

A portfolio consists of one or more business initiatives realized by a set of epics.  An epic may need one or more release cycles to be fully implemented.  As shown in Figure 5, the business initiatives for Portfolio 1 are to be realized by a set of M epics: Epic 1.1, Epic 1.2 …to Epic 1.M.   Most of these epics are business facing, but there may be few that are architectural epics necessary to build an architectural runway.  An enterprise may have multiple portfolios. Each portfolio consists of a set of programs.  Program planning is done after the parent portfolio-level planning.    A program consists of a set of features needed to realize an epic.  Recall that each feature is small enough to be implemented in a single release cycle.  Some people suggest taking swag at estimating effort at the portfolio level judging “bigness” of epics on a linear scale of 1 to 5 or 1 to 10 or a Fibonacci scale of 1, 2, 3, 5, and 8.  However, swags are in a different scale than team story points, and not normalized in any way.

Let us see an example of CNM top-down estimation as illustrated in Figure 5.


Figure 5: Portfolio-level planning and CNM top-down estimation

The baseline story is the lowest-level in hierarchy. In our example the baseline story (Story is estimated by the team to take 21 ideal hours.  This number is divided by the Normalization Basis (40 hours in our example) to calculate the NSP for the baseline story.  The NSP for the baseline story comes out to be (21/40) = 0.52, shown inside the gray oval below the baseline story in Figure 5.   Now all other stories in the baseline feature 1.1.2 are estimated in terms of their relative sizes, i.e., Team Story Points (TSPs) compared to the baseline story.  This can be done by playing Planning poker or any other technique.  In Figure 5, story is 2x compared to the baseline story, and story 1.1.2.k is the same size (1x) compared to the baseline story  These TSPs are shown in yellow ovals below story and 1.1.2.k.    Therefore, the NSP for story is (2 * 0.52) = 1.04 and story 1.1.2.k is of (1 * 0.52) = 0.52 NSP.  NSPs of all stories of the baseline feature 1.1.2 are rolled-up (simple addition) to calculate NSPs for feature 1.1.2 (which is 4.32 NSP shown in gray oval next to feature 1.1.2).

Going one level up to the program level where features are managed, efforts for all features of the baseline epic 1.1 are estimated in terms of their relative sizes (so-called “feature points”) compared to the baseline feature, and those feature points (now expressed in NSPs) are rolled up to the next higher-level, i.e., the epic level.  Feature point estimation can again be done by playing Planning poker or some other technique for relative size comparison.  In Figure 5, NSPs for all features in the baseline epic are shown, and their roll-up at the baseline epic 1.1 is also shown.  The baseline epic 1.1 is thus estimated to take 23.3 NSP.

Going one level up to the portfolio level where epics are managed, efforts for all epics of the portfolio 1 are estimated in terms of their relative sizes (so-called “epic points”) compared to the baseline epic, and those epic points (now expressed in NSP) are rolled up to the next higher-level, i.e., the portfolio level.  Epic point estimation can be done by playing Planning poker or some other relative size estimation technique.  In Figure 5, NSPs for all epics in the portfolio are shown, and their roll-up at the portfolio level is also shown.  Portfolio 1 is thus estimated to take 163.5 NSP, which is same as (163.5 x 40) = 6,540 ideal hours of work.    Of course, this number is a rough estimate.

Thus the estimation of effort at portfolio, program and team levels follows a common pattern, and hence this approach has fractal (i.e., “self-similar”) elegance.    The effort estimate now available at the portfolio-level is better than swag or any other gut-feel estimate.  It is also in units that can be converted into estimated cost based on the known loaded cost for one NSP of work (either based on historical data or loaded cost estimate for one NSP for the portfolio).    Note that team story points, feature points and epic points are relative sizes of stories, features and epics.  They are used for conceptual understanding.  CNM converts all of them into a single currency, which is the Normalized Story Points.

Based on this effort, quick calculations can be done to estimate how many sprints or release cycles will be needed to complete the estimated work for the given capacity of each team.  This is essentially Fix Scope – Flex Time agile planning mentioned earlier.   For example, if Agile Capacity for each sprint for the portfolio is 400 hours, at least (6,540/400) = 17 sprints of time will be needed.

If there is a deadline of only 12 sprints of time, the portfolio capacity is only (12 x 400) = 4,800 hours.  As the estimated work is 6,540 ideal hours, approximately (6,540 – 4,800) = 1,740 hours = (1,740/40) = 43.5 NSP worth of lowest rank-order epics from the portfolio backlog need to be removed from the scope.   This is essentially Fix Time – Flex Scope agile planning mentioned earlier.    Let us say, you decide to remove Epic X and Epic Y from the portfolio backlog (lowest rank-order epics), which would remove 35 NSP, falling 8.5 NSP short of the target of 43.5 NSP scope reduction.   If you were to select an entire Epic Z (estimated scope of 12 NSP) for removal, you would end up reducing the scope too much.  You can deal with this problem by breaking Epic Z into its member features and estimating and rank-ordering those features to identify few lowest rank-ordered features (with a total of 8.5 NSP) for scope reduction.

The estimates for both Fix Scope – Flex Time and Fix Time – Flex Scope planning are rough estimates only; but they can be explained in a meaningful and consistent way by using NSP measure; these estimates then become a starting point for conversation for evaluating different options.  Portfolio or program planning based on swags or “bigness” gut-feel numbers do not offer these benefits.

Estimation at the program level

The details of estimation at the program level follow the same pattern described above for the portfolio level.  The only difference is that the highest level now is the program level instead of the portfolio level.  Each program in a portfolio is estimated by its own program leadership team.  Each program leadership team does the estimation of effort for the baseline feature at the program level following the approach described above in portfolio estimation.

We now have more information available because for each program in a portfolio, we are identifying the baseline feature; and for the baseline feature of each program, we identify its baseline story.   As an example, if we have 4 programs in a portfolio, we identify 4 baseline stories and estimate them in NSP.  We now have more lower-level data available, which improves the reliability of estimates.  This program-level estimate allows us to revise and refine the estimates done earlier at the higher portfolio level.  Based on these revised, new estimates, some decisions taken earlier may be revised or refined.  This is how progressive elaboration and estimation should work.

Estimation at the team level

This was already covered in great details in Part 4 of this blog series.  Once you have estimates at the team level, all stories are now estimated in NSP across all teams for a sprint.  All that information can be rolled-up level by level giving us more detailed, refined and revised estimates than what was done earlier during program-level or portfolio-level planning.  Based on these revised, new estimates, some decisions taken earlier at program and portfolio levels may be revised or refined.

Portfolio-level and program-level planning sessions take place before team-level planning sessions.  Sprint planning is done by each team for each sprint (typically 2 to 4 week sprints).  Teams in a program should ideally do program-level planning jointly for each release cycle (3 to 6 month release cycles).   Portfolio planning is done by the portfolio leadership team covering multiple release cycles (6 to 12 month planning horizon).

Normalization math

The Capacity_Workload_Calculator.xlsx downloadable template handles all math required for Agile Capacity calculation, and workload estimation at the portfolio-level, program-level and team levels.   You should start with its Instructions worksheet, and follow the instructions to use all the remaining worksheets.

  • Normalization Basis worksheet: Enter the Normalization Basis for your enterprise.
  • Team_Capacity worksheet: Used by each team to calculate its Agile Capacity for each sprint. The team capacity automatically flows to Team_Workload worksheet so you can easily compare the estimated workload for a team against the Agile Capacity for the team to find out if the team is overloaded or has excess capacity.
  • Portfolio_Workload worksheet: Used to calculate the estimated workload of a portfolio in NSP and equivalent ideal hours.
  • Program_Workload worksheet: Used to calculate the estimated workload of a program in NSP and equivalent ideal hours.
  • Team_Workload worksheet: Used to calculate the estimated workload of a team in NSP.

The CNM and the Capacity_Workload_Calculator.xlsx downloadable template have been used by my clients over many projects since 2010, leading to several refinements culminating into the current version of CNM and the template as described in this blog.

How CNM deals with all three challenges listed in Part 2.

  • Challenge 1: A single story point is unlikely to represent the same amount of work across space and time
    SAFe’s 1NM requires each team to find 1 IDD story as benchmark, and does not recommend any re-calibration.  Its Calibration Size is 1 IDD, and its Normalization Basis is also 1 IDD, i.e., 8 ideal hours of effort.  On the other hand, CNM decouples Calibration Size and Normalization Basis.  It simply determines Calibration Size based on sprint by sprint re-calibration, if needed.  This a more robust normalization technique based on TSP re-calibration for every sprint if required, which responds to changing reality sprint by sprint.  Story points are normalized properly across both the space and time dimensions.
  • Challenge 2: Bottom-up story point data is not available for estimating work during program and portfolio planning
    In this Part 5 of the blog series, I have presented the details of how CNM addresses the issue of top-down estimation at the portfolio and program levels without requiring the knowledge of story points for all team-level stories.
  • Challenge 3: Yesterday’s weather model requirements may not apply.
    CNM does not require any historical velocity data.  When a team has no or little historical velocity data, it simply calibrates (or recalibrates) its Team Story Point based on a sample of up to three stories.     CNM does not depend on yesterday’s weather model requirements.  For each sprint, it recalibrates its Team Story Point and recalculates its Point Conversion Factor if any requirement required for yesterday’s weather model is not going to be met; if yesterday’s weather model is applicable, you may use the average velocity (in NSP) from the last 3 to 4 sprints to estimate the velocity for the next sprint (in NSP).  Recalibration effort based on up to 3 sample story points may take approximately 20 minutes (a smaller sample of 1 or 2 stories will take less time).  But this is done only once for a sprint during its sprint planning.  Once the Agile Capacity is calculated (a 15 minute exercise using the template provided with this Part 5 of the blog series), estimation of velocity expressed in NSP for a sprint is a snap.    Challenge 3 is a non-issue for CNM as yesterday’s weather model is neither assumed nor required to hold true.

Comparison between 1NM and CNM

SAFe is a complete framework for managing large scale agile projects.  CNM is not a scalability framework, but only a method for scalable agile estimation.  Table 1 shows a comparison between SAFe’s 1NM and my method CNM.

Swags use yet another currency of effort in an enterprise besides story points and ideal hours.  These three currencies have no relationship.  Having three unrelated currencies for estimating effort is confusing and unnecessary.    Unless you normalize story points in a large enterprise, story point math and planning based on story points will not make sense.  For the same reasons story points may lose meaning without normalization, swags too may lose meaning without normalization.  Normalized story points are naturally related to ideal hours and provide a single currency for estimating effort across the space and time dimensions.  A single-currency world is much simpler to understand and manage.

Summary and concluding remarks for the blog series

Estimates are estimates, and not commitments or contracts.  This fact does not change with scalable agile estimation methods using normalized story points.  Scalable agile estimation can be classified based on the degree of centralized vs. distributed decision making, as illustrated in Figure 6.  Mike Cohn’s method (covered in Part 3 of this blog series) is an example of the centralized class.  Another example of the centralized class is the method of “cross-team synchronization on points with a canonical set” (briefly covered in Part 3) by Larman and Vodde (Practices of Scaling Lean & Agile Development, Chapter 5, pp. 182-183).  As explained in Part 3, centralized methods are difficult to scale for large-scale agile projects.   SAFe’s normalization method, 1 NM (also covered in Part 3) is an example of the semi-distributed class; each team is allowed to select its own 1 normalized story point benchmark (decentralized operation), each team must select a story of 1 IDD (8 ideal hours) effort as 1 normalized story point (NSP), which is a centralized decision.  CNM is fully decentralized as each team is free to select its own 1 Team Story Point (TSP) story, and no team is required to select 1 TSP of any pre-defined size (let the chips fall wherever they may).


Figure 6: Spectrum of Scalable Agile Estimation Methods

In conclusion:

  • CNM can be applied to small (even single-team) agile projects, very large agile projects consisting of multiple portfolios and programs, and enterprises with a large number of independent projects.
  • CNM deals with various challenges in estimating large-scale agile projects, and offers advantages over centralized and semi-distributed methods.
  • CNM is not tied to any specific agile scalability approach or framework, such as SAFe.  However, CNM can be used in conjunction with SAFe.
  • SAFe’s normalization method, 1NM, can be considered as a special case of CNM.
  • CNM is not tied to any commercial agile project management tool.
  • A free downloadable template makes agile capacity calculation and story point normalization math quick and easy.
  • CNM promotes local, decentralized, and autonomous decision making at the team level by allowing teams to use their own story point scales.
  • Using top-down estimation techniques and baseline estimates, portfolio and program estimates based on CNM are more credible than swags or gut-feel numbers.
  • CNM-based portfolio-level normalized estimates become more relevant as they are revised when more information becomes available about lower-level story estimates and teams’ actual velocities.
  • CNM supports Fix time/Flex scope as well as fixed scope/flex time planning.
  • CNM has been continuously refined based on user feedback from clients since 2010.
  • CNM offers a solid foundation for consistent estimation across large-scale agile projects.

If you would like to receive a single file version (as a PDF document) of this 5-part blog series, please send me an email at requesting the document.

I hope that you have benefited from this comprehensive 5-part blog series.  Please provide feedback and/or comments via: or twitter: @smthatte.

Acknowledgements: I have greatly benefited from discussions and review comments on this blog series from my colleagues at VersionOne, especially Dave Gunther, Andy Powell and Lee Cunningham.

Part 1: Introduction and Overview of the Blog Series – published on 14 October 2013.

Part 2: Estimation Challenges Galore! – published on 4 November 2013.

Part 3: Review of published scalable agile estimation methods – published on 7 November 2013.

Part 4: Calibrated Normalization Method for Bottom-Up Estimation – published on 18 November 2013.

Posted in Agile Adoption, Agile Methodologies, Agile Metrics, Agile Portfolio Management, Agile Project Management, Agile Teams, Agile Velocity, Distributed Agile, Enterprise Agile, Scaling Agile, Scrum Methodology | Leave a comment

Agile Portfolio Management, Continuous Integration and Scaling Agile Come to Agilepalooza

Agilepalooza Austin is set for December 6!  We are excited to share the thinking of our presenters, who are speaking on topics like continuous integration, scaling agile enterprise-wide, agile portfolio management, and more.  

We’ve got six presenters total, and I’ve included three sound bites to give you an idea of the level of content you can expect to receive.

Dave Sharrock of Agile42 will explain to you what it is really like to take on the impossible with “Herding Cats!  The Art of Agile Portfolio Management.”  Dave says the problem of practicing agile at the team level has been solved, but now the challenge is scaling agile to multiple products and projects.  Navigating through personal interactions and differing priorities is as important to the success of the project as visibility.  Dave will talk on each of these to connect the “why’s” and help you make accurate decisions on where to spend time and budget dollars.

Damon Poole with Eliassen Group wants to “Unlock the Power of Agile in Your Organization.”  Per Damon, most practitioners use 5% of the value of agile during the scaling of a project. How can this be?  If you take the overall length of the project, from the idea phase through production, the only agile work being done is coding and testing.  When agile encompasses more than that– the full project process–it can mean tens of millions of dollars to a company.  He is going to share his ideas on how to find that missing 95% of agile value and how to translate it into a cost savings for your product and company.

Jann Thomas of LeadingAgile will conduct a workshop for her portion of the day, “Begin with the End In Mind: Continuous Integration for the Rest of Us.”  Her six-question maturity model will determine where you are in your continuous integration efforts and how you move forward as a team.  She will also identify the needs of management and the next steps to take to get to the next level.  The hands-on retrospective approach will give you a great overall picture of current company status and some clear action items on your continuous integration efforts to use when you are back in the office.

Three other speakers will be joining us including David Hussman of DevJam, John Sigler of Sabre Airline Solutions and Mike McLaughlin, VersionOne agile coach.  The day will move fast and the information, faster.

There are still some spots left for the December 6 session at the AT&T Conference Center in Austin.  You can register for Agilepalooza Austin here or reach out to me at for more details.

Posted in Agile Portfolio Management, Continuous Integration, Enterprise Agile, Uncategorized | Leave a comment