The Agile Community to Join Forces in Detroit: @AgileAndBeyond

Agile and Beyond: the words paint an image of a dark, star-lit sky. The starship Agile floats through the air toward some distant, efficient, high-performing process improvement.

Excuse the attempt at a dreamy, poetic intro; I’ve got Valentine’s Day on the brain.

Good news; this thinking need not be conceptual dreaming. Agile and Beyond, coming to Detroit next week, brings a place and platform for healthy discussions and dialogue around agile software development’s past, its present, its future.

It’s Agile and Beyond time again, and VersionOne is proud to be a returning sponsor at the conference on Saturday, February 22nd in Dearborn, Michigan.

Stop by and visit us at Agile and Beyond to learn what you need to know about managing your company’s agile processes with an agile project management tool, or continue to evolve or adapt your understanding and execution of agile.  We are the first booth on the left when entering the sponsor area.

Agilists from across the Midwest will gather in Dearborn, Michigan for Agile and Beyond 2014.

Agilists from across the Midwest will gather in Dearborn, Michigan for Agile and Beyond 2014.

When you are not visiting our booth, check out the great slate of sessions available.

From reading the titles and abstracts, these are my favorites:

Stop Thinking and Start Doing: Action is everything, right? In this presentation, Daniel Davis will explore how we can use agile to put noble goals in place for you and your team. This will be personal development at its finest.

The Power of Promiscuous Pairing:  In this provocatively titled talk, Thomas Piggott and Carol Treat Morton will showcase how pairing can yield tremendous benefits even beyond development. Who wouldn’t want to attend a talk that helps your team eliminate ‘towers of knowledge?’

Removing the UX Roadblock: Anyone who has been on an agile team with UX talent knows the struggles. A developer’s work styles, patterns, and pacing may be completely different than a UX designer’s, yet the designer’s contributions and output are pivotal to producing software. Stop thinking of the UX team as a roadblock; instead visualize them as a high-performing team member capable of greatness.

We are just scratching the surface here with the number of awesome presentations and workshops on the schedule.

Thanks, Agile and Beyond for putting together another outstanding event. We look forward to meeting the agile software development community of the greater Detroit area.

BTW: If you have time after the conference, visit one of the great Middle Eastern restaurants that call Detroit home. You won’t be disappointed.

Dan Naden
Community Marketing Manager


Posted in Agile Software, Agile Tools, Scaling Agile | 1 Comment

Can a Team be Scrum without Retrospectives?

Sometimes Twitter is just a bunch of crap and noise.

Other times, stuff comes over that you just can’t ignore. After we published the State of Agile report, I had one of those moments.

It hit me after one dude tweeted something to the effect of: “How in the world can a team claim to be doing Scrum if they don’t practice retrospectives?” I couldn’t let this one go. I polled our staff of professional agile coaches. Within an hour, 6 of them had opinions on whether you can proudly call your team “Scrum” or even “Agile” without conducting regular continuous improvement procedures.


Here I’d like to share with you some of our coaches’ opinions and recommendations – then find out your take. (ADHD moment: If you are new to agile or wondering ‘what is a retrospective?’ here’s a good explanation).

Take this as FREE advice from our professional coaches. Normally you pay for this stuff so IF you enjoy it, you at least owe me a LinkedIn share or tweet @VersionOne.





“You can’t be ‘Scrum’ if you aren’t doing all of the practices of Scrum.” – Steve Ropa

True. But I give this statement a big “So what?” Isn’t the goal of agility to create great software? If some part of Scrum doesn’t work for your team, should you do it anyway just so you can be Scrum?  In the words of John Pinette, I give this a “nay nay.” I recommend doing all of the practices to start with – and only removing or modifying practices when you find them to be unnecessary or even detrimental. Ironically, teams usually come to that conclusion during the retrospective.

You can be agile without retrospectives, but it’s a very, very rare team who can. I have run into a few. They’ve usually been doing XP for a while, and are always co-located.  Some teams did the retrospective because they were supposed to, but never really came up with anything new.  What they were able to do was to inspect and adapt at the drop of a hat. These teams also found that daily standups had become redundant.

“It’s the wrong question to begin with.” – Lowell Lindstrom

The question of whether or not a team can be “Scrum” is a red herring for a few reasons.

First, due to the inherent inspect-and-adapt nature of Scrum, over time, no two teams will be identical and any given team may evolve in a way that makes one of the common or defined parts of the Scrum framework suboptimal. The classic example of this is task articulation and estimation in Sprint Planning, which many agile teams find is not necessary as they improve.

Second, there is no one person who can designate whether or not a team is Scrum, leaving any assessment to the discretion of the assessor. Across experts in the various Scrum communities there is a little consensus. This is due largely to the first point, i.e., the fact that each person’s opinions will be shaped by their experiences. And these are inevitably different.

It’s worth noting that the original definition of Scrum didn’t even include retrospectives. The patterns and papers from the mid-90s, and Ken Schwaber’s first book on Scrum (2001) make no mention of retros. The focus was on the product with the Sprint Review at the end of each Sprint, but no explicit reference to the team’s PDCA. Similarly, the original definition of Extreme Programming (XP) did not include retrospectives.

In 1999/2000 as XP was gaining in popularity, Norm Kerth was writing his book Project Retrospectives: A Handbook for Team Reviews.  Although focused on larger, longer projects and the difficulty of learning what really happened, the ideas resonated strongly with the XP community and we soon saw the practice added to the XP list. The Scrum community followed suit and in Ken’s next book on Scrum (2005), we see retrospectives become part of the framework as we know it today.

So, were teams doing Scrum from 1993-2005 not considered ‘Scrum teams’ because they didn’t do retrospectives? Of course they were; it’s a silly question. What we can say is that the Scrum community and its leaders have found that the most hyper-performing teams reflect on their practices with a tenacious attitude toward improving the way they develop. Most do this through the construct of the retrospective. However, doing retrospectives well is difficult and depends on a culture that values learning. So, if my retrospectives suck and yield no improvement, then am I really any closer to being Scrum than if I do not do them at all?  I would argue: No.  Is a team who uses most of the Scrum framework but not retrospectives, integrating PDCA into their daily work as the Kanban community advocates, still a Scrum team?  I would argue: Yes.

Any discussion centered on “being” Scrum or “doing” Scrum should explore whether a practice improves a team’s performance, the different scenarios and conditions required for a practice to thrive, and the substitutes that might make a practice replaceable.

“Retro is a key ceremony. You cannot be ‘true’ Scrum unless you follow the framework as it was designed.” — Jo Hollen

You can, however, be “ScrumBut”… and realize some value from your partial Scrum efforts.

Going back to agile and Lean principles, the notion of continuous improvement is very foundational. Without retrospectives, I would be concerned about how the culture is addressing the principle of continuous improvement. Do such organizations have other methods through which they can incorporate team feedback and address improvement? Maybe the more interesting examination is why do they NOT want to do a “retrospective” – or not think they need to?  I’ve seen where they were done as part of the process, but often I felt they were not very effective in many teams.

First, it must feel totally safe to bring up something that is not going well.  Many cultures still want to immediately find a person to blame for the “problem.” If anyone feels unsafe, the retrospective will be superficial. Nothing useful will come from it, and the team will quickly find the retro a waste of time.

Even if a team gets to the point of bringing up real issues, there must be a spirit of appreciation for the input – then real results and follow-through.  If nothing ever comes of the feedback, it will quickly stop. Besides, if results are not implemented, then there is no improvement anyway (thus, another waste of time).

Or maybe the team feels that everything is fine. REALLY??? Nothing can be improved? (Maybe you should hire them for coaches then). Even the highest-performing teams will find things that can be improved. But, maybe every two weeks feels too often? Maybe they should do a health-check/status and a deep-dive examination every few sprints. Agile requires some form of engagement and commitment to continuous improvement.

“You can’t be ‘Scrum’ without the ‘Scrum’ ceremonies.” – John Krewson

You can be agile without the ceremonies so long as you’re adhering to the principles, but “Scrum” asserts certain ceremonies as part of the framework. Those ceremonies, retrospectives included, are intended to uphold the theory of empirical process control upon which Scrum was built. I refer to retrospectives as the “missing agile value” and have a blog post coming out soon to address this.

“Learning always precedes agile maturity.”  — Brian Irwin

As you’ll see in John’s blog post, from an organizational perspective, learning always precedes agile maturity. I’m also planning a blog post specifically about expanding retrospectives past the team level and embracing them at all levels in the organization, including (or especially) at the upper-management level.

To me, one of the most critical aspects of agility is learning; i.e., at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Maximizing learning is also a key Lean concept.

I think people tend to get so hung up on processes and how to do things that they forget why they’re doing them in the first place.  But to answer the question directly, if you’re not doing retrospectives not only are you not doing Scrum—you’re not really agile if you aren’t making time for learning. Teams typically stop doing retrospectives because they’re difficult. Once you’ve addressed the low-hanging fruit, it gets complex to address the real hard stuff (people issues, organizational dysfunction, etc.).

“Not doing retrospectives suggests the plan must be perfect.” — Michael Moore

I would say that this is not specific to Scrum so much as it’s one of the principles of agile to inspect and then adjust/tune.  This principle goes beyond agile even; I’m not sure I’ve seen any good improvement method that doesn’t include some sort of periodic reflection and adjustment, whether it be self-improvement or organizational.

Not doing retrospectives suggests that there is no need for adjustment, which means that the team and plan must be perfect.  If they aren’t, however, this activity is essential to maximizing effectiveness.

Of all the principles, this is the first that should be implemented, regardless of the method. From this principle, all other principles and practices are discoverable.


Can a team be Scrum or Agile without retrospectives? Join the debate by leaving a comment below. Better yet, subscribe to this blog; several articles addressing this topic are on deck from our coaches in the upcoming Agile Chronicles. We’d like to hear from you!




Posted in Agile Adoption, Agile Methodologies, Scrum Development, Scrum Methodology | 7 Comments

Education Led Transformation

Guest post from Alex Adamopoulos, founder/CEO of Emergn Limited

In the 1960s the Center for Creative Leadership (CCL) developed the 70/20/10 model, a model that demonstrated how people learn best when it comes to doing their jobs. The study showed that lessons learned from successful and effective managers were:

70% from tough jobs, experience / 20% from people (managers, bosses) / 10% from courses and reading (classroom instruction)

In 1996, two of the original members of the CCL study on the 70/20/10 model wrote the book “The Career Architect Development Planner.” With more empirical data and evidence, they were confident in stating:

“Development generally begins with a realization of current or future need and the motivation to do something about it. This might come from feedback, a mistake, watching other people’s reactions, failing or not being up to a task – in other words, from experience. The odds are that development will be about 70% from on-the-job experiences, working on tasks and problems; about 20% from feedback and working around good and bad examples of the need, and 10% from courses and reading.”  (Lombardo and Eichinger expressed the rationale behind the 70/20/10 model this way in The Career Architect Development Planner).

In the last five years we’ve seen the exponential demand for new thinking in organizations. When I say “new thinking,” I mean new ways of doing our old jobs. This exponential demand is largely credited to adoption of both agile and lean practices. The early years of Scrum and XP have demonstrated that developing and delivering software can be drastically improved but also that many agile practices can now be applied successfully in other core areas of an IT and business organization. The early years of lean showed us that Lean Six Sigma was a good initial foray into compressing DMAIC and taking the idea of lean from the manufacturing floor to the corporate world. We’ve now learned that lean, on its own, is more than adequate without other process models attached to its hip. Lean Startup is a testimony to this.

In all of it, however, companies still spend enormous amounts of money on sending people to training classes in order to learn these new skills; plus they bring in external consultants to coach and mentor. There is value and need in both of these investments, but if we are truly interested in transformation, then we need to look further and outside the traditional methods. This goes back to the 70/20/10 model and why it’s more relevant now than ever.

Part of the answer when we discuss transformation lies in two important questions: ”What do we mean by transformation?” and “What are we transforming?” History tells us that traditional two-day Scrum training has had little effect on helping organizations change how they work. We see a similar challenge with the dependence on tools. Just as some believe that tools will inherently solve problems, two days of training on anything simply cannot product lasting results. Only motivation, perhaps, and some formation of good ideas can help. This is the 10% component of the model: learning from courses and reading (classroom instruction). To emphasize, this is still important, but it’s not the whole picture, nor does it serve the real need: how we help people change the way they do their work and how to make that change stick.

The 70% component of the model: learning from tough jobs and experience is where the real learning sticks. This requires the consistent and repeated application of practices and principles on real work — something in which you are engaged at your company where you can begin to see immediate results and understand why change matters. This approach, often referred to as work-based or action learning, is new to the agile and lean market; yet, it is quickly becoming the new normal. Think of it in the form of these statements:

  • You want to introduce agile and lean thinking to improve your customer experience and overall business performance
  • You want to invest in what’s most valuable to your organization: your people
  • You want to retain your best people and provide a learning journey for others so that they become your best people
  • You want to improve, even change, the way you deliver your services and products to gain market share and increase brand equity
  • You want to leverage “just enough” external expertise and not be heavily dependent on someone else
  • You want to do all this in the shortest timeframe possible with the maximum results and most reasonable cost
  • All this is what you mean by transformation

I expect there are more statements you’d add, but to achieve these we need to bring it back to how people learn. A systemic learning approach will always provide greater value and lasting benefits. Incremental and disparate training that is purely content- or classroom-driven simply cannot product the same, compelling results.

Education Led Transformation is a phrase that has come to mean many things for me in the last year; mainly it has been a re-awakening that organizations improve only when people do. Oh my, this is so obvious that it even seems trivial to say, but haven’t we all fallen into the trap that processes and tools are so much more important? Isn’t this the reason the Agile Manifesto was so key in saying, “individuals and interactions over processes and tools?” Isn’t it still, and won’t it always be about people?

Therefore, we conclude that learning AND development are so much more important and so much more than just training. They bring a lifestyle of learning and applying; this is why leading with a systemic, work-based learning approach is so fundamental to the cause. Yes, I’m a bit biased to the work-based (action) learning topic, but indeed I’ve now seen too many examples of how impactful it truly is.

“I hear and I forget;
I see and I remember;
I do and I understand.”


Posted in Agile Adoption, Agile Coaching, Agile Teams, Agile Training, Lean, Scrum Development | 1 Comment

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