Using 7 Product Dimensions to Slice User Stories

When listening to agile teams I coach, I hear that right-sizing user stories is one of the biggest challenges they encounter. In fact, Mike Cohn gave some advice about splitting reporting user stories, which generated a lot of comments and discussion on his blog.

Because this is such a hot topic, I was interested in attending a webinar hosted by Scrum Inc. CEO and Scrum co-creater, Jeff Sutherland, which featured Ellen Gottesdiener, titled: "Getting Your User Stories Ready: Slicing and Visualizing." Gottesdiener is co-author with Mary Gorman of the book "Discover to Deliver: Agile Product Planning and Analysis," and I’d been wanting to learn more about the seven product dimensions that I’d heard about. Gottesdiener did an excellent job of providing examples of how the seven dimensions can be applied to “slicing stories” (a term she prefers over “splitting stories”) appropriately.

Gorman and Gottesdiener have been teaching how to slice stories to optimize value for a while. In "Slicing Requirements for Agile Success," they write:

To do that [provide high-value working software], teams and business customers need to jointly explore requirements options, identify the most important ones, and slice chunky stories into manageable pieces. The optimal slicing technique would be reusable in all problem domains, leverage the discipline of requirements analysis, be quick to learn and efficient to use, engage product owners (a.k.a. customers), put the “user” back into user stories, directly feed into acceptance tests, and deepen the entire team’s knowledge of the requirements.

Gottesdiener and Gorman tend to teach by example. Their book starts out with a case study about a fictitious window cleaning company, so that the reader can see end-to-end examples of how the processes and dimensions are applied. As with any agile process, refinement continues over time with a continued cycle of discovery and delivery.

In order to create a product of high value, the seven product dimensions are used for each product option identified. Partners, falling into three groups: business, customer and technology, are identified and each group identifies the value sought from the product option. A plan is created for delivering the product option and structured conversations are used for ongoing collaborative discovery.

Regardless of initial size of the product need, which may be expressed in a variety of ways--feature, use case or story, for example--using structured conversations, alternatives are explored, which then lead to product options.

Let’s take a look at each of the seven product dimensions that are used to clarify each product option:

User: How will users will interact with the product? Interface: How will the product connect to users, systems and devices? Action: What capabilities does the product provide for users? Data: What type of data and information is needed and where is it stored? Control: What type of constraints does the product enforce? Environment: What type of physical properties and technology platforms must the product conform to? Quality attribute: What quality attributes constrain and control the product?

Gottesdiener and Gorman teach teams how to use discovery sessions with visual thinking and visual language to help stakeholders come to consensus on appropriate product requirements and how to create the right level of detail in their user stories. Using low-tech tools, sketches, diagrams, colored sticky notes and most importantly, structured conversation, teams collaboratively come together in reaching consensus on highest-value product requirements.

I’ve barely scratched the surface in this blog post on how these processes and tools can be used. The model is one that provides a systematic solution to a difficult problem. Check it out and let me know what you think!  

What Is Scrumban Anyway?

One thing that I really love about writing industry articles is that I’m constantly learning what’s new or trending. For example, all in the same week I was asked by Techbeacon if I would write an article about Mixing Scrum and Kanban, invited to review the book, The Scrumban [R]Evolution and invited to a Distributed Agile Meetup group in which the topic was Scrumban.

When my Techbeacon article was published, it immediately got plenty of hits and shares on social media, so apparently, the mixing of Scrum and Kanban is a topic that a lot of people are interested in right now!

Before reading “The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban” by Ajay Reddy, my experience of mixing Scrum and Kanban was one in which we basically used Scrum, but without the time-boxed iterations.

The team still held the “ceremonies” recommended in Scrum: the standup meeting, planning meetings, demos and retrospectives. We even calculated velocity and used story pointing for estimates. We had a product backlog, but not a sprint backlog, so basically, the main thing we didn’t do that is mandated in Scrum is that the team did not have a set of stories that they were time-bound to have completed by the end of an iteration.

Though we didn’t have an “end-of-sprint review,” again, we did have demos and retrospectives on a monthly cadence. Planning sessions were at least weekly, with often a second scheduled in the week if needed.

My impression was that we were using “Scrumban,” though I hadn’t been aware of the formal definition of Scrumban, or even if there was such a definition. When I looked up Scrumban in Wikipedia in order to prepare for the article I was writing, I found that the opening paragraph states:

Scrumban is an Agile management methodology describing hybrids of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban. Today, Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work.

The definition and much of the rest of the Wikipedia article uses material from Reddy’s book, though does mention Corey Ladas, the person who coined the term, Scrumban:

When Corey Ladas introduced the world to Scrumban in his seminal book, Scrumban: Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Press, 2009), he boldly defined it as a transition method for moving software development teams from Scrum to a “more evolved” software development framework.

However, the paragraph goes on to state that Scrumban has “evolved” to the methodology described in “The Scrumban [R]Evolution:”

In actual practice, however, Scrumban has itself evolved to become a family of principles and practices that create complementary capabilities unique from both Scrum and the Kanban Method. These capabilities have led to three distinct manifestations.

Wikipedia continues on with a brief overview of the manifestations as well as processes described in Reddy’s book.

Overall, I believe Reddy provides a model that would be useful in large-scale environments, though much like the SAFe methodology (which also uses both Scrum and Kanban, by the way), some agile purists may find it too prescriptive.

I’m not sure I’d agree with the statement in Wikipedia that this is the actual practice that is used when people use the term “Scrumban,” or that Reddy’s model is the definitive Scrumban methodology. In fact, even Reddy writes early in his book:

Although Scrumban has evolved as a framework over the years, it has no definitive guide or definition. In fact, as highlighted early in this book, several “authoritative” sources disagree about what Scrumban actually represents.

However, I’m not sure if there needs to be agreement on the actual term. What’s more important, in my opinion, is understanding the lean and agile concepts and principles and applying them in the context of your organization.

Before deciding whether you want to use Scrum, Kanban, Reddy’s version of Scrumban, SAFe, or your own custom hybrid methodology, first become educated on the pros and cons of the different methodologies.

Start with what you believe would be a good fit for your organization, and then regularly reflect, adapt and improve.

Unique Tips for Effective Team Meetings

Meetings have a reputation for being a huge waste of time. Though meeting management is nothing new, here’s some recent advice from a few different sources that provide some unique tips for meetings in today’s modern world.

Build Relationships

In his article, “6 Ways To Get Rid of Bad Meetings, Once & For All,” David Dye lists these tips for effective meetings:

Only hold meetings when they’re the most valuable use of all attendees’ time Build relationships Achieve results Get the right people in the room Set expectations about how a decision will be made Include accountability in every decision

Dye expands upon each of these tips with suggestions of how each can be done well. For example, when he says to “build relationships” (one that typically doesn’t make it on a “Top 6” list for effective meetings), he lists three types of conversations that can foster relationships:

Cultural conversations to problem solve or celebrate Elephant-in-the-room conversations to openly discuss sensitive issues Mutual-help conversations to discuss how people, teams or departments can support one another Giving People the Chance to Opt-In

OfficeVibe, an organization aimed at improving employee engagement, produced a video called “The Culture Blueprint” in which Rob Richman from Zappos was interviewed about creating a company culture.

Richman had some interesting ideas and hacks and takes the idea of empowerment to the extreme. For example, he suggests that one of the best culture hacks an organization can do is to make meetings completely optional. He says:

See who shows up. One of two things will happen. One is, if you’re afraid people might not show up, they might not. Which means your meeting’s not that relevant to their job, or it’s not that interesting and then that’s on you. But what oftentimes happens is that instead, the people who you thought will show up, might not, and the people who you thought might not have any interest, will show up. And then you’ll have one of the most energized meetings you ever had because everyone really, really wants to be there. Distributed Meetings

Despite the agile recommendation of face-to-face communication, distributed meetings are a reality in today’s world. ven co-located teams often have conference calls in order to accommodate someone who may be working from home or off-site.

Sococo, a vendor that provides a tool for hosting distributed team meetings, also has a blog with great advice. In their piece, “10 Meeting Rules to Live By For Distributed Teams,” they recommend:

Improve every day accessibility Just don’t have unnecessary meetings Choose the right medium Appoint a facilitator Implement time limits Stand up … or even “plank up” Consider time zones and timing Commit to a meeting style Record meeting notes in accessible shared files Set expectations

Read their post for the complete run-down on the specifics.

I’ll add one more:

Make an effort to engage remote participants.

If there are both face-to-face participants and remote participates, have at least one person be responsible for making sure the remote participants can hear and know what’s going on in the room.

Remind people in the room to speak into microphones and if video cams aren’t available, have someone responsible for IM’ing remote employees to describe what’s going on and to check in on their ability to hear, see and participate.

We all know the common rules of running a smooth meeting, such as having a clear agenda. However, there are still many valuable hours wasted by people being in unproductive meetings.

What creative ideas do you have to make sure meetings are effective? Let me know in the comments below!

The Problem with Quality Metrics

CA Technologies came out with a report, “The Impact of Agile. Quantified,” which looks at four dimensions of performance: Responsiveness, quality, productivity and predictability.

The report compares these performance metrics in different situations. For example, when you have dedicated team members, the numbers show your productivity, measured with throughput, doubles.

The report notes, however, that correlation does not necessarily mean causation:

For example, just because we show that teams with low average WiP have one-quarter as many defects as teams with high WiP, doesn’t necessarily mean that if you lower your WiP, you’ll reduce your defect density to one-quarter of what it is now. The effect may be partially or wholly related to some other underlying mechanism.

The study included comparisons of performance metrics based on how teams performed estimates. The four different estimating processes that were compared were

No estimates “Full Scrum” with tasks estimated in hours “Lightweight Scrum” with estimates using story points only Only task hours estimated

The key findings were:

Teams doing full Scrum have 250 percent better quality than teams doing no estimating. Lightweight Scrum performs better overall, with better productivity, predictability and responsiveness.

Personally, I think that this is a case where, despite the “key findings,” I don’t think a team’s estimating processes is the cause of differences in quality. In fact, I don’t trust any of the numbers having to do with quality because I don’t agree with the way quality is being measured.

My issue with the report is the same issue I have with many other quality reports: Quality is measured by number of defects alone, when in reality, those numbers can be very misleading.

Having spent many years as a QA Manager, I know that defect counts are very commonly used in quality measurements, and as I wrote about in this article, I believe that is a very poor indication of quality, especially when you’re comparing across different projects.

Here are some of the problems with using defect count as a measure of quality:

Defect count does not take into account the severity of the defect. Defect count does not take into account the definition of a defect, which may vary greatly on different products. Defect count does not take into account the way the defects are being collected. And perhaps, most importantly, defect count does not take into account the number of users using the product.

This last point was made clear to me when I was working on a team which was given an award for “Best Quality” because there were zero reported defects. The application had been internally released, though I hadn’t felt it was ready because testers were easily still finding bugs.

While I was happy to get an award, it didn’t make sense to me that this application could win a quality award. On further investigation, I found out that the reason there were no customer defects reported was because not a single person was using the new application.

On further reflection, I realized that the applications which typically had the most reported bugs were those which were used the most. I realized that these were not necessarily poorer quality than other applications; it’s just that they had far more users and the users cared enough about the application to take the time to report the bugs.

There are no easy answers when it comes to measuring quality, or many of the other performance factors, for that matter. Teams that use “full Scrum” may, in fact, generally produce higher quality code than those who don’t estimate.

However, if you want to improve your quality, I think teams would be best to focus on getting feedback from their customers. Make it easy for your customers to give you feedback.

We want to eliminate defects, sure. However, let’s remember that quality is about more than defect counts. We need to hear from our customers, and whether you call that feedback “requests for enhancements,” “defects” or “customer comments,” consider that feedback a positive thing that will help us continue to improve.

Are Agile Teams Happier Than Traditional Teams?

I’ve had a big interest in positive psychology in the last few years, subscribing to a lot of newsletters and blogs that are centered on happiness-related topics. I even started my own blog about workplace happiness and I’m always pleased when I see articles about happiness being passed around in agile forums.

For example, I first read the article, “Positive Teams Are More Productive,” because it was shared on a LinkedIn Agile Coaching Group Discussion.

While I don’t think working in an agile environment is a guarantee of workplace happiness, there are certain ideas and leadership practices known to improve workplace happiness that are encouraged in agile teachings.

The Growth Mindset

I asked Michele Sliger, a well-respected agile coach who was speaking at the Boulder-area agile user group meeting if she felt agile and positive psychology were related. Her answer was that agile promotes more of a “growth mindset” versus a command and control type of environment, which would contribute to a happier workplace.


In Daniel Pink’s book, “Drive,” he lists autonomy, purpose and mastery as three primary intrinsic motivators for employees. With agile’s emphasis on servant-leadership and self-organizing teams, employees typically have much more autonomy than they get in traditional hierarchical organizations. Agile cultures also promote innovation and continuous improvement.

Individuals and Interactions

Perhaps the biggest contributor to happiness in the workplace has to do with our relationships with the people we work with. Individuals and interactions over processes and tools is a value statement in the Agile Manifesto, and if there is a strong culture of respect, kindness and caring in the workplace, people tend to be happier.

Sustainable Pace

One of the 12 principles of agile is: “Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.” Basically, this means that people should not be expected to work long hours, but rather that a healthy work-life balance will ultimately result in a happier, more productive employee.

According to the post, “What is Sustainable Pace?,” working too much is a regret many have at life’s end.

Sustainable Pace is not about taking it easy and going slow. It's just the opposite, you should expend energy vigorously, and regain strength by resting. In the long run, make sure you invest your energy wisely, and set your priorities taking into account the findings of happiness research.

My personal experience is that I’ve been both happy and unhappy on both traditional and agile teams. If I think back about the times when I’ve been unhappy at work, it’s because these principles and values were not actually practiced, even when the organization was using an agile methodology.

On the other hand, I’ve also been in traditional environments where I felt very respected by my peers and management and was given the autonomy I needed to feel happy.

Happiness is difficult to measure and even if we could measure it, it probably wouldn’t be that useful to conclude whether or not agile teams were happier than traditional teams.

The question really is: Are you and your team happy? If not, what can you do to help bring about positive change?

One thing we can always control is our own mind and attitude. Find the positive and be a change agent in your organization for creating a happier workplace.

Giving and Receiving Constructive Feedback

When I teach classes, I have a retrospective at the end of each day, inviting students to use sticky notes to put items in the three columns:

What worked? What could be better? What do we want to do tomorrow?

Throughout the day, I also play a game where students earn points for demonstrating agile behaviors. During the retrospective, after everyone has put up their sticky notes, I give double points for those items listed in the “What could be better” column.

Why? Because for most people, giving constructive feedback is difficult. No one wants to be viewed as “negative” and there’s also fear of hurting someone’s feelings. However, constructive feedback is important in order to continually improve. It’s the primary purpose of having a retrospective.

Receiving constructive feedback is even more difficult than giving it. We often DO take it personally, as much as we try not to.

I know that every time I teach a class, I tell myself that I MUST demonstrate what I’m about to teach: No matter how negative I perceive the feedback, I must not act defensive or like my feelings are hurt. It’s important to show people that giving constructive feedback is safe.

There are many lessons on how to give and receive feedback, but here are two I learned from participating in groups where feedback is given in a very formulaic way.

Lesson 1: Ask Everyone to Contribute at Least 1 Positive and 1 Constructive Piece of Feedback

As I’ve written in why fearless feedback is critical to agile development success, a lesson I learned from Toast Masters is how to give a good evaluation speech, sandwiching constructive feedback between positive feedback.

However, beyond the lesson of softening the constructive feedback by including what is going well, the other aspect that provides an element of comfort here is that constructive feedback is expected.

Though the feedback may not carry as much weight if it’s formulaic, it gives both the giver and receiver an avenue to both give and receive difficult feedback.

Instruct those who are giving feedback to list at least one thing that worked well and one thing that could be better, even if they have to dig deep.

Getting feedback this way takes away the sting of an unexpected or unsolicited criticism. This also gives those giving the feedback permission and the safety to say what they feel and not worry they will be viewed as negative.

Lesson 2: Remember That Not Everyone Feels the Same Way

The other lesson I learned was from my writing group. It was very common in critiquing writing that two of those critiquing would have completely opposing viewpoints. One person may have said they absolutely loved a certain passage of an essay, while another may have considered it unnecessary or boring.

However, there might be other areas of the same essay where pretty much the whole group was in agreement that the passage was especially good or that it really needed work. Since everyone in this group was interested in writing, they typically had the gift to articulate specifically what they did or didn’t like about the work.

This phenomenon occurred so often that it became very clear that as a writer, it was important to not stress over a single negative opinion, but really poll the group and focus on the areas where there was consensus.

You cannot please everyone when you’re working on something creative. However, having a deeper understanding of the criticism really helped clarify that subjective works will result in differing opinions. This also allows everyone’s opinions to be heard and considered.

This is true in our work as well. When you have a retrospective, do not rush out to solve every issue that’s brought up without first discussing with the group. Some people may not agree with one person’s feedback. Focus on the areas where there is consensus on obvious need for improvement.

Giving and receiving constructive feedback is not easy, but it’s one of the most important aspects of the lean-agile mindset.

The next time you receive some uncomfortable feedback, challenge yourself to accept it graciously, learn from it, and then, rather than feeling sad, hurt or upset, feel grateful and excited to be able to improve.

Speaking a Common Language in Agile

In the various agile classes that I teach, I've found most of the students have learned terminology dependent on the agile methodology their organization uses as well as the tools they use, the corporation they work for, their business domain and various other factors.

Often, corporations will adapt a methodology to their needs and create their own custom way of doing things. But all this adaptation can create some confusion when it comes to talking about, writing, teaching and learning agile. It would be nice if the industry could standardize a few things.

First, Do We Capitalize the ‘A’ in Agile?

Let’s take a very simple thing that shouldn’t really matter, but as someone who has written for various industry publications, primarily about agile methodologies, it matters to me: Do we capitalize the letter “A” in “Agile?”

There are various opinions (believe me, I’ve listened to hours of discussion over this) about capitalizing it when it’s used as a noun, but not as an adjective, always capitalizing, never capitalizing or capitalizing when it describes “mindset,” but not when it is used as an umbrella term for various methodologies. [Editor’s note: We lowercase “agile” here at Front Row Agile, but find the discussions fascinating.]

And if there’s this much debate about when to capitalize the word agile, you can’t imagine the debates about what the word actually means in the context of software development! It seems like in almost every class I teach, there’s at least someone who says something like, “We’re supposedly using ‘agile’ [in air quotes, of course], but we’re doing it all wrong.”

Understanding the ‘Why’ Behind the Rules

Whenever someone says this, I ask more about what they feel the organization is doing wrong. They might say something like, “We only have stand-up meetings every three days for an hour instead of daily for fifteen minutes.”

If the answer is something like this, then I realize that they’re talking about Scrum rather than agile, and they think the problem is that the organization is not following the right rules. We might take this back to the agile principle about the business and developers communicating daily and find out whether it causes a problem to communicate 3 days a week for an hour rather than 5 days a week for 15 minutes.

If it doesn’t cause a problem, then there’s no need to change it, just because there’s a “rule.” If it does cause a problem, then the team needs to inspect and adapt. But, just because a team doesn’t follow all the Scrum rules, does not mean they aren’t agile.

Terminology of Product Backlog Groupings

But I’m digressing from my original message: Lack of standardization of industry terms used in agile methodologies is adding more confusion to an already confusing, and sometimes, hotly debated topic.

My pet peeve? Terms used for items on the product backlog. The Scrum Guide refers to these generically as “product backlog items” or “PBIs” which is an easy way to avoid debate about whether they are capabilities, themes, features, epics, user stories or some other word floating around out there in agile literature.

There seems to be common agreement that user stories are of a size that they can be completed in an iteration (also called sprint), should provide business value and should be sized using story points.

One level lower than a user story is commonly called a task. But when you want to group a bunch of user stories together, well, it might be called an epic or a feature or maybe something else, depending on the tool or methodology.

Another area that can cause huge debate is the definition of “program” versus “project” versus “subproject.”

In the end, it doesn’t really matter what you call it, as long as you all understand what you’re talking about. In my opinion, it’s best to avoid saying something is “right” or “wrong” when it comes to definitions of agile terms.

Just like it’s important to understand the “why” behind a rule rather than just blindly following it, it’s more important to understand the “what” behind a term if it seems like there’s miscommunication.

Before deciding your team is doing agile “wrong,” make sure you’re all speaking a common language. Then work together to figure out what issues there are, and how you might improve.

You can call that plan-do-check-act, a retrospective, inspect and adapt, continuous improvement or agile. Or you could avoid all the buzzwords and just call it good old-fashioned common sense. 

Teaching Social Intelligence and How It Relates to Agile

Being an agile trainer, I’m always interested in new techniques in teaching, and one of the blogs I subscribe to is that of Georgia teacher, Vicki Davis. Davis is not an ordinary teacher, however. She uses project-based learning and technology designed to teach compassion and empathy.

I listened to a presentation given by Davis at the “Education: Next Generation” conference titled, “Using Projects to Teach Compassion and Technology.”

I was particularly interested because soft skills are not typically taught in a classroom, yet skills such as social intelligence and emotional intelligence are particularly important for success in agile environments.

These are the types of skills that are so important for agile leaders, yet it seems that they’re rarely taught in the classroom.

Davis, author of the book, “Flattening Classrooms, Engaging Minds,” and podcast, “Every Classroom Matters,” teaches her students to become “social entrepreneurs” by tapping into their “heartbreaks,” and helping them to create apps that will do something to help address those heartbreaks.

“What are the things that break your heart and why? How can we do something to address that heartbreak?” are questions she asks her students. “It’s a great technique to get kids excited about their opportunity to change the world,” she says.

The kids have created apps to help with issues such as human trafficking, cutting and cancer.

The apps can be found on the site,, and not surprisingly are developed using agile and lean techniques, including Kanban.

In her talk, Davis talks about several concepts that we teach in agile management classes, such as empowerment, the growth mindset and capitalizing on the strengths of individuals.

Though Davis is empowering and focusing on strengths of students, she pointed out the importance of these skills in the workplace and that if bosses focus on the strengths of their staffs, studies have shown a dramatic increase in employee engagement.

Another parallel to agile teaching was Davis’s emphasis on the importance of conversation.

“It’s the conversations that change everything,” she says, giving examples of times where conversations between teacher and student can set the trajectory for growth, confidence and self-esteem that will lead students to meet their full potential knowing someone believed in them.

Davis talked about the importance of ensuring everyone had a voice in conversations, reminiscent of what we teach Scrum Masters.

She uses Socratic dialog, teaching with questions, but uses techniques to ensure that it’s not only the extraverts who are speaking up.

One way she does this is by giving students three poker chips. They use a poker chip when they contribute to the conversation, but once their chips are gone, they can’t speak until everyone’s chips are gone.

This puts pressure on the quiet ones to use their chips by speaking up. Though this may take them out of their comfort zone, Davis has found that this technique has exemplified that everyone has something to bring to the table.

Another skill Davis teaches her students is how to “professionally disagree.”

In talking to them, she will sometimes say something that she knows the student doesn’t agree with to see if they will challenge her. If they don’t, she’ll talk to them about why they didn’t speak up, and they’ll often answer that they didn’t think it was appropriate to disagree with the teacher.

She’ll then go on to teach them how they can respectfully speak up when they hear something that they disagree with. She wants the students to question. If something doesn’t make sense, ask why?

It’s encouraging to hear that Davis is teaching skills beyond the traditional, but really delving into these areas of social and emotional intelligence.

These students will become future leaders who will lead with empathy and compassion.

Already, these students are making a difference with the apps they are creating. For Vicki Davis, she finds meaning in helping the students make that difference.

Learn more about her teaching methods here:

Vicki’s website – Cool Cat Teacher Mad About Mattering website

Time Management and Agile

A while back, I received a Scrum Alliance newsletter announcing that at Global Scrum Gathering Bengaluru 2016, the keynote speaker, Kiran Bedi, would be speaking on the topic of time management.

I’ve been interested in time management since the early 90s, way before the Agile Manifesto was penned, so I thought it a little unusual that this rather ageless topic would be chosen for a Scrum gathering, but then I realized that many agile practices do, in fact, have commonality with techniques taught in time management.


I’ll never forget a lesson I learned from my first time management class. The instructor asked the class, “If someone asked you to pick up a package that was an hour out of your way on the way to work, what would you say?”

Most students agreed that they would say something to the effect of being too busy. Then she asked, “What if I told you that there was a million dollars in the package that you’d get to keep?”

Of course, you’d drop anything else you were doing and make it a priority to get that package. If it meant being late to work, so be it. The worst that would happen would be you’d get fired, and with a million dollars, you just may decide to take the whole day off!

The instructor reminded us that when we use the phrase “I’m too busy,” what we’re really saying is “That’s not a priority for me.”

Next, we went through the exercise of figuring out our priorities--our big life priorities, yearly priorities, monthly and so on. Now that I’m familiar with Scrum, I realize we were creating our life’s backlog.

With software, we’re looking at a product and requirements on a backlog, and we need to continue to prioritize them and ensure they are aligning with our top priorities or our vision. As we prioritize, we weigh the value to the risks or consequences if those things didn’t get done, just like we do when we make any decision.


Another Scrum concept that can fall into the time-management category is that of time-boxing. Scrum is big into time-boxing meetings, such as the 15-minute stand-up meeting, and, of course, time-boxing the iteration itself.

Though some people find time-boxing frustrating because of the sense of pressure it can create, it can also help in creating discipline in completing tasks. The other big advantage to time-boxing is that it provides a mandatory stopping point so that feedback can be gathered. Many activities could go on indefinitely without being time-boxed.

Perfectionism will prevent many people from stopping and getting feedback. Think about the author who never is done with that novel, or the projects that get started, but never finished. Creating a time-box helps you focus, make progress, collect feedback and improve.


One more concept that was adopted from lean methodologies and is commonly referred to in agile circles, as well as time management literature, is flow, or elimination of waste.

Basically, I think of flow as when your mind is totally focused on what you’re working on. You’re in “the zone.” Things like multitasking are discouraged because there is waste associated with task-switching.

One of the Scrum Master’s responsibilities is to remove obstacles for the development team so they are able to focus and not be distracted by unnecessary interruptions.  

A few methods I’ve seen used effectively to stay focused are:

1. The Pomodoro Technique – a technique where you set a timer and stay focused during that time frame.

2. Declare a “No Meeting” policy for your group on certain days or periods. This might be Wednesday afternoons, for example.  

3. Have a visual cue to others (such as putting on headphones) that communicates that this is a time that you shouldn’t be interrupted.

In this day and age when we are constantly multitasking, checking smartphones and email, it can be tough to stay focused and productive. There are a variety of apps and techniques dedicated to helping people become more productive and better manage their time.

What are your favorites?

What to Do When the Team Complains About Agile Processes

I recently attended a Lean Coffee event at a Denver-area agile meetup. The group was asked to come up with issues they were struggling with and then, after a vote, we had time-boxed discussions on those topics that generated the most interest.

The topic that I found the most interesting was: What do you do when the team complains about agile processes?

As with most things related to agile, there is no one-size-fits-all answer. What one team may find cumbersome, another team may like.

Almost everyone seemed to have examples, however, of times during which they were on teams that were unhappy about at least some agile processes.


The first thing a Scrum Master, coach or agile servant leader should do when they have an unhappy team is to listen to the team and understand the root cause of the issues they're experiencing.

“Try to get them to understand the why behind the processes,” someone advised. If the team can come up with another way to satisfy the end goal, then maybe it should be explored.

Not only do you want them to understand why processes are in place, but you also want to understand the team’s concerns with the processes.

“Ask several ‘whys’ and get to the root of their fundamental fears,” advised someone from the group.

Examples of root causes seemed to fall into two categories ...

1. Issues with the Tools

In many of the examples that were given, the issues seemed to be related to the tools being used rather than the fundamental agile principles. If tools are slow or filled with heavy processes that take a lot of the team’s time, they aren’t going to like them.

Though we all know that agile promotes individuals and interactions over processes and tools, the reality is that in large organizations, teams often don’t have much control over the processes and tools that are being used. If every team used their own favorite tools and processes, the lack of consistency would cause chaos.

That being said, if tools and processes are creating unnecessary waste, the team might be able to suggest ideas to reduce that waste. The teams may not be able to change which tools they’re using, but perhaps they can work together to come up with some organizational suggestions that could lighten up the processes.

2. Teams Are Not Getting Enough Support

The other category of issues that people brought up related to lack of management support. Stories included teams who were uncomfortable with estimates.

“It took a year for them not to be scared to commit,” said one Scrum Master of a team he’d coached. “As a Scrum Master, you need to help them.”

But how to help them? Again, start by understanding the root cause of why they’re scared to commit. What happens if they miss their commitments? Who holds them accountable and how?

Though agile promotes self-directed teams, the reality is that many organizations are still operating in command-and-control cultures.

The Scrum Master may need to not only coach the team, but also coach management.

There are no easy answers, but start by listening and truly understanding the issues. Then, elicit the help from the team, making sure everyone’s voice is heard.

In the end, you want to empower the team to help solve the problems they’re experiencing.

Stop the Multitasking, Listen and Engage

I’m a huge advocate for distributed teaming and the flexibility and variety of benefits we can get from a work-from-anywhere culture. However, especially in agile circles, co-location is pushed hard.

Though I hear over and over again the challenges of things such as time zone differences or cultural differences as barriers for distributed teams, I rarely hear mention of what I think is one of the primary problems when working remotely: Multitasking!

When you’re on a conference call where you can’t be seen, you’re much more likely to put yourself on mute, and keep working on whatever you think is a higher priority, just barely listening for a mention of your name or something you think you might need to know.

In fact, even when there are conference calls across sites, and many people are in the room, I’ve been in many a meeting where someone puts the room on mute so that side conversations can happen, even while someone is presenting.

If we were physically in the same room with the speaker, out of respect, most people would at least pretend to be listening.

But when you can’t be seen or heard, it gives license to not pay close attention, and so we multitask, chat or play with our phones during the parts of the call where we think we can get away with it. (Perhaps holoportation will solve these types of problems in the future.)

Focused listening can be difficult, even if we’re co-located. These days we’re constantly interrupted with texts, phone calls, tweets or emails our devices deem important with a variety of notification beeps, quacks or ring tones.

People are distracted with their smartphones, even when they are talking one on one with someone in person, so much so that it’s almost become the new norm to multitask constantly, preventing us from gaining the beautiful benefits of connecting with a person instead of a computer.

Though I’m totally a fan of multitasking in certain situations (for example, I love to listen to podcasts while exercising), it’s a huge barrier for effective one-on-one communication.

I fully believe that distributed teams can be just as effective as co-located teams, but if you are working remotely, it’s more important than ever that you learn to practice strong communication and teamwork skills from a distance.

That means you need to stop the multitasking during conference calls and start listening and engaging.

I teach both face-to-face and virtual classes, and, of course, the face-to-face classes are easier for me because I’m able to see the body language of the students and do activities to keep them engaged.

However, during virtual classes, we play games throughout the class so that the students can participate via chat, being the first to answer a question or cheering on a teammate. The other day, one of the students used his webcam to show us his new adorable puppy! Now that’s something that doesn’t normally happen in a co-located class.

Many of the problems that keep us from communicating effectively, such as multitasking, are happening regardless of where we’re physically sitting.

We need to recognize our own poor habits and work to enhance our communication. This is especially important if we don’t have the benefit of communicating in person.

So, stop the multitasking and, whether you are face to face or remote, when you’re communicating with someone else, find a way to listen attentively and share your smile.

Holoportation: The Newest Way to Virtually Communicate

If you’re a fan of the sitcom “Silicon Valley,” you may remember a scene in which there is a holographic teleconference meeting. Gavin is teleported and his 3D image appears to be in the room with the others in the meeting.

It turns out this new type of 3D communication is not as futuristic as it may seem. In fact, Microsoft Research has been working on the 3D capture technology dubbed “holoportation,” allowing high-quality 3D images of people to be transmitted in real time to a remote location, creating a mode of communication remarkably similar to that shown in the “Silicon Valley” episode.

By using a HoloLens, a headset created by Interactive 3D Technologies, a user is able to see the reconstructed image of someone who has “holoported.”

This video demonstrating the technology shows how the 3D image is seen to someone wearing the HoloLens. It appears as if someone remote is actually in the same room!

Of course, in that “Silicon Valley” episode, there were technology issues; first with the holographic teleconference, then, with the video conference, and finally, even with the cell phone.

Even though new technology is awesome, there are often complications and growing pains, which can cause frustration for new users or early adopters. The good news is that the issues continue to get fixed and the technologies continue to improve.

Who would have believed how easy it is now to communicate “face to face” even when we’re not physically co-located? With tools like Skype and Google Hangouts, just to name a couple, video chats and conferences have become simple.

Now we are literally taking communication to a whole new dimension with 3D communication. Though this technology is still in its infancy, it will undoubtedly improve and someday we may find it hard to remember a time when it wasn’t available.

Though I don’t believe any mode of communication can completely replace the connection that results from being physically together, the ability to communicate real time in 3D is another big step in face-to-face communication.

Some people criticize technology for taking away our “real life” social connection, but I think if used well, technology helps us enhance the social connections that are most important to us.

For example, the stronger our communication and collaboration tools are, the more freedom we have to be spending our physical time with the people and in the places that mean the most to us.

Thanks to advancements in technology, employees have more options to telecommute or avoid work travel and spend more time with their families.

In recent years, I’ve known many people who have been able to spend time with ailing parents and still accomplish their work by taking advantage of tools that help distributed teaming.

In my opinion, employers are really putting “individuals and interactions over processes and tools” when they give their employees the freedom to spend time with their families, as long as they’re able to do their job well.

Holoportation is the latest, greatest innovation in communication. Though it may be a while before it’s mainstream, I’m excited to see how this new technology will be used and how it will grow and improve over time.

What do you think? 

Is 'Host Leadership' a Better Term Than 'Servant Leadership'?

When my grandfather made a toast, he often raised his glass first higher than the other glasses and said, “Never above you,” and then lower, below the others, and said, “Never below you,” and then clinked the glasses at the same level, finishing with, “Always beside you.”

Apparently, the quote originated from Walter Winchell, reminding us that our place is often best, not in command or in servitude, but together, in unity. Might this be best in leadership as well?

I admit that I’ve never been entirely on board with the term “servant leadership” or the often stated sentiment in agile circles that managers need to “get out of the way.” Luckily, in most organizations I work with, teams understand that servant leadership is not meant to devalue the talents of the leaders, but rather to be in opposition to a traditional command-and-control style of leadership.

Servant leaders are taught to empower self-organized teams by trusting them with more decision-making responsibilities and to eliminate unnecessary micromanagement waste.

The term “servant leader” was originally coined in 1970 by Robert Greenleaf in his essay, “The Servant as Leader.” The idea is to “serve first” and in so doing, become a stronger leader. While certainly giving employees and teams more autonomy has been proven to lead to higher-performing teams, it seems that “host” leadership rather than “servant” leadership, would align more closely to the emphasis on teamwork focused in agile.

Pierluigi Pugliese, in the article, “I’m Not a Servant – I’m a Host! A New Metaphor for Leadership in Agile?” provides several examples of why “leader as host” seems to be a better description than “leader as a servant.”

Host leadership, a leadership style alternative developed by Marc McKergow and Helen Bailey, see the leader not as a hero nor a servant, but as a host who receives and entertains guests.

The host leadership model is described in the book, “Host: Six New Roles of Engagement for Teams, Organizations, Communities and Movements,” published in October 2014. The six roles: initiator, inviter, space creator, gatekeeper, connector and co-participator, can be played from four different positions: on the stage, among the people, on the balcony, and in the kitchen.

The combinations resulting from mixing role to each position result in 24 styles that might be used for leadership, depending on the context.

For example, the space creator role is used to create an environment, either physical or emotional. The on the stage position is used when the host leader is the center of attention. An example of the combination of the space creator + on the stage would be when a host leader explains the purpose of a meeting.

In my opinion, understanding and applying the complete host leadership model is not necessary to becoming an effective leader. My issue is not with servant leadership as it’s being applied in today’s world, but rather with the term “servant.”

I believe team members as well as servant leaders are all meant to both serve and lead, depending on the circumstance and context. Though servant leadership was a big step in the right direction as an agile leadership model, host leadership may be an even better model for developing strong teams.

Do Engineers Like Agile Development?

I’m an engineer. I come from a long line of engineers. I married an engineer, and two of my three kids are engineers. I’ve worked with engineers my entire career, so I consider myself quite in touch with a typical engineer’s personality.

So, do engineers like agile development? If we look at the typical engineer’s personality, there will be traits that align with agile values and other areas that take engineers out of their comfort zone.

One of the most common personality type tools is the Myers-Briggs Type Indicator that results in 16 MBTI types, depending on four scales, which we’ll review below.

Engineers usually fall into the Introversion and Thinking categories. In the article, “Personality Types and Agile Development,” Richard Banks, as an INTJ, believes his own personality type is a great match for agile because INTJs are adaptable.

Banks suggests that an ISTJ would be more suited to Waterfall development because of the tendency to prefer a more methodical, traditional approach.

I can tell you as an ISTJ myself, I do prefer a plan and structure, but I believe agile methodologies do give us that, just not in the same manner as Waterfall.

With that, let’s take a look at the four Myers-Briggs scales to see how a typical engineer personality may or may not align.   

Introversion (I) vs. Extraversion (E)

The first scale is Introversion vs. Extraversion. Introverts get their energy from being alone. Most of us introverts prefer to work alone rather than as part of a group.

Think back when you had a school assignment to be done as a group. If you were an introvert, you probably inwardly groaned and just figured you’d need to do the lion’s share of the work yourself to ensure it was done “right.”

It’s not that we don’t like people, it’s just that we don’t want to have to depend on them.

The “whole team” approach used in agile is probably one of those areas that takes many engineers out of their comfort zone.

That being said, engineers are known to want autonomy, so the emphasis on self-organizing teams will most likely appeal to engineers, as long as they feel good about who’s on their team.

Sensing (S) vs. Intuition (N)

The Sensing vs. Intuition scale describes how we take in information. Do we prefer using external sources, such as our senses (S), or do we rely more on gut instincts and intuition (N)?

Those with a high “N” value are more visionaries and are comfortable with abstract, futuristic thinking. Those with a high “S” value are concrete and realistic, giving attention to present details.

I believe either of these personality preferences would feel comfortable with agile development. Though, strong S people like detail, and that detail emerges in agile development before development work is done.

However, S people may feel uncomfortable starting development without a solid framework or architecture in place.

Thinking (T) vs. Feeling (F)

Thinkers and feelers are distinguished based on how they make decisions. Thinkers make decisions based on logic and reason and feelers rely more on subjective feelings based on their value system.

Engineers are almost always strong T personality types. They are logical and rational.

Though this type of personality works well with coding tasks and getting work done, engineers may feel uncomfortable with some of the team-building activities encouraged on agile teams.

In my experience, engineers bond best by solving tough problems together and may view an outing as a waste of time.

Judging (J) vs. Perceiving (P)

The Judging and Perceiving categories have to do with how much structure and planning in daily life is preferable. Those who have strong J personality types like schedules, plans and lists. Those who are stronger P types act spontaneously and decide things more at the last minute.

Agile development teaches us to plan “just in time,” remain adaptable and accept frequent change. This would cater more to the P personality type.

However, the J personality type takes great pleasure in bringing tasks to closure, so the agile style of decomposition with a specific set of tasks to accomplish will tend to align well with engineers who have a strong J personality type.

In sum, there are bound to be some things that engineers like about working on an agile team and some things that make them uncomfortable.

It would be best for the Scrum Master or agile leader to recognize the individual personality preferences of each team member and perhaps discuss as a team.

While each individual is different, when they all understand and respect one another's tendencies and preferences, they will undoubtedly become a stronger team.

Adding Disruption to Spark Creativity

We learn with ShuHaRi that as we move to new levels of mastery, we must continue to experiment – to step out of our comfort zones and do things differently than they’ve been done before.

In his TED Talk about disruption, journalist and economist, Tim Harford, gives us examples of how being forced to deal with unexpected challenges can spark creativity and open up new and better ways of doing things.

He starts with a story about a pianist who needed to play a concert on a defective piano in a new way, which ended up being the best-selling piano recording in history.

Harford goes on to give other examples and says that research has shown that people experience discomfort, yet “unexpected advantages of having to cope with a little mess.”

Around the 8-minute mark, Harford describes how we solve complex problems, including software development, step by step, just as we encourage with agile development:

“You have some kind of prototype and you tweak it, you test it, you improve it.”

He agrees that this is a good way to solve a complicated problem, but tells the audience what would make it an even better way:

“A dash of mess. You add randomness, early on in the process. You make crazy moves, you try stupid things that shouldn’t work, and that will tend to make the problem-solving work better. And the reason for that is, the problem with the step-by-step process, the reason for the marginal gains, is they can walk you gradually down a dead end. And if you start with the randomness, that becomes less likely, and your problem-solving becomes more robust.”

Harford’s next example was from social psychology describing an experiment in which two groups were asked to solve murder mystery problems.

One group was a team of four friends and the second group was a team of three friends and a stranger.

The groups with the three friends and a stranger were 25 percent more effective at solving the problem; however, what Harford found even more interesting was how the teams felt.

The teams who performed better, felt doubt and were not as confident or comfortable, because working with a stranger added disruption:

“Disruptions help us solve problems, they help us become more creative. But we don’t feel like they’re helping us. We feel like they’re getting in the way. And so we resist.”

Harford’s final example was the story of Brian Eno, a brilliant ambient composer and catalyst behind some of the greatest rock ‘n’ roll albums of the last 40 years, having worked with David Bowie, U2, Devo and Coldplay.

Eno purposely creates disruption for bands through the use of a deck of cards called the Oblique Strategies.

When they're stuck in the creative process, they grab a card and they need to follow the instructions.

Examples include: “Swap instrument roles,” “Look closely at the most embarrassing details. Amplify them.” “Make a sudden, destructive, unpredictable action. Incorporate.”

Harford says that though the musicians hate the cards, they’ve proved their worth album after album. Though these experiments are uncomfortable, the musicians ended up realizing something: Just because you don’t like it, doesn’t mean it isn’t helping you.

In the software development world, disruption is often introduced, not purposely, but by the unexpected request or obstacle. We could look at these obstacles as opportunities to creatively solve problems.

What if we were to create an Oblique Strategy deck for agile teams? What kinds of things would they include?

How about switching roles for an iteration? How about swapping team members? How about making all meetings optional?

Besides helping promote creativity, if we purposely introduce “mess,” might it also help us better cope with the unintentional messes that are thrown our way?

Experimentation is disruptive, but encouraged in agile communities. Though Scrum and other agile methodologies give us a framework, as teams mature, take time to experiment with new ideas and creatively grow as a team.

Harford ends his talk reminding us that even though it’s uncomfortable, disruptive behavior helps us grow and learn:

“All of us, from time to time, need to sit down and try to play the unplayable piano.”

The Problem with the 6th Agile Principle on Communication

The sixth agile principle from the Agile Manifesto states: 

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This may be true. Certainly, there are a lot of reasons that face-to-face communication is a rich form of communication. However, a lot of changes have happened since 2001 when the Manifesto was first written and we now have opportunities to take advantage of different types of communication.

Social media, the cloud, and mobile technologies give employees the opportunity to work from anywhere, and most of us want to take advantage of that flexibility. However, many employers don’t allow this because “it’s not agile.”

But what about that principle? Is it “anti-agile” to participate on a distributed team? Though I don’t know if all agile coaches would agree with me, my answer to that is a big, fat “No!”

Personally, I think it’s kind of anti-agile to insist that teams must be co-located, but I also think it’s anti-agile to call anything anti-agile, so let’s just say the agile thing to do is to adapt to your context and circumstances.

Understand the issues and the pros and cons of different solutions or why a certain practice (in this case, face-to-face communication) is encouraged, and ensure that objective is being fulfilled.

We want the team to effectively and efficiently communicate, but there are ways to do that in today’s modern world, without having to work on face to face daily.

Before getting into some of the advantages of distributed teams, first let’s look at some negative outcomes I’ve seen as a result of the insistence of face-to-face communication being necessary for effectiveness:

- If there are any “remote” members – even if they’re temporarily traveling or working from home – they feel excluded and don’t have the latest information because the team is using processes and tools that depend on physical locality.

- People who are face to face feel that they are communicating “more effectively and efficiently” than those who are remote. This may result in a self-fulfilling prophecy. If teams feel they’re at a disadvantage, their mindset and attitude will be different than if they feel positive about the diversity and advantages of distributed teaming.

- Teams that are globally distributed may ask some team members to come to daily Scrum meetings outside of business hours in the name of having face-to-face meetings over telepresence or webcam. However, because of cultural differences or communication difficulties such as heavy accents, written communication may be easier and clearer for everyone. Being forced to come in off-hours may build resentment, not closeness between team members.

- Though strong team relationships can form from the bonds and friendships that grow from co-location, this may result in clique-ish behavior. Strong communication and teamwork is something that needs to be fostered, not only between team members, but also between stakeholders, other teams and various supporting groups. Invariably, these people will not all be co-located.

- Agile team members may be asked to come into the office every day when their colleagues who don’t work on agile teams are allowed the flexibility of some work-from-home days. This can lead to resentment at not being allowed the same privileges as others.

- Agile team members may be asked to sit in a workspace that promotes “osmotic communication.” However, the resulting additional noise and lack of privacy can frustrate the team member who will often wear headphones to drown out the noise, thus defeating the purpose.

- When there’s a conversation without follow-up documentation, there is later debate about what was discussed and agreed to. Two parties often remember things differently or have different understandings. Documentation can help to make sure everyone is on the same page.

While, again, there are advantages of face-to-face communication – deeper trust, the ability to read body language, the deeper relationships that can be formed, positive osmotic communication, the ease in explaining a technically challenging concept – we now have tools that weren’t available in 2001 when the sixth principle was created that can help us with these objectives.

As agilists, let’s remember to adapt and look at all the additional forms of communication we have available to us in 2016, and use those to foster teamwork, regardless of where team members physically work.

3 Steps to Learn + Connect with Agile Experts via Social Media

Though books are a wonderful way to learn, beyond all the wonderful pages of information and writing, we have a new dimension available to us now – we have access to the actual people behind the words.

Thanks to social media, we can now personally learn from the experts, speakers, thought leaders and authors.

In my opinion, this is like having access to the most awesome library imaginable! It’s priceless, yet it’s available for free!

We can ask questions, debate and discuss theories, tools and techniques. If we read something that we don’t quite understand, we can go directly to the author to dig deeper, explore, dissect and innovate.

And what’s more, we can even become friends … not just superficial “virtual” friends, but form real-life connections based on shared interests and mutual respect.

Take any topic and you will most likely find others who have similar interests on LinkedIn, Facebook and Twitter.

If your interest is agile topics, there are hundreds of agile groups on LinkedIn, and agile pundits tweeting about everything agile. All you need to do is join in the conversation!

There is so much available, in fact, that it might seem overwhelming to know where to begin. Start with understanding your objectives. Are you trying to learn a particular methodology? A tool? Gain experience and knowledge to beef up your resume?

For those new to social media, I’d suggest these three phases of participation similar to the ShuHaRi model of mastery:

1. Read, Learn, Connect

2. Comment, Discuss, Share

3. Create, Write, Teach

1. Read, Learn, Connect

Start with finding social media related to the topics that interest you most. You can find blogs, LinkedIn Groups, forums, ebooks, courses, podcasts, SlideShare presentations, YouTube videos and other avenues to learn.

Many authors offer free ebooks in exchange for your subscription to their mailing list.

If you don’t have a LinkedIn account yet, get one and create a profile. LinkedIn is the best social media site for business and careers.

Then, whenever you read or learn from someone, request to connect to them via LinkedIn. Let them know in your request that you are interested in learning more about their topic and thank them for the blog post or whatever it was that led you to them.

Follow them on Twitter, subscribe to their blogs, and “friend” them on any social media that they advertise on their sites. If you find that you’re getting too much email, you can always unsubscribe, change your settings or set up an RSS feed.

However, by connecting to these experts, you will naturally be led to others as these connections post links or pass along information about similar agile circles and communities.

2. Comment, Discuss, Share

Bloggers love to get comments. Even if your comment is simply a “Thank you for your post,” your comment is appreciated and will help raise engagement on the blog.

Likewise, simple likes, re-tweets or sharing through various social media channels will not only help to establish you as someone who is interested in these topics, but will also help strengthen your connection with the authors.

Sharing a post or tweet is so easy, and it’s really a win-win. You are doing a service to others in the community by sharing information and the author feels happy for the recognition.

Taking this one step forward would be to add a longer comment with your own experience or ask a question. Once again, the authors will appreciate that you took the time to engage in discussion and will welcome respectful dialog.

This is another opportunity to form a connection with the thought leaders. If you are someone who comments on their material, they will recognize your name and you’ll gain some visibility as someone who is interested in learning and sharing.

LinkedIn Groups also give the opportunity to pose questions and engage in discussions with others with similar backgrounds and interests.

3. Create, Write, Teach

Finally, as you gain expertise, start your own blog or discussion forum. When I was laid off in 2009 and looking for a QA management job, I started a blog as a way to learn, network and gain some credibility, should anyone decide to “Google” me.

I started by blogging about everything I was learning from all these different social media avenues. Then I branched into interviewing other QA managers I’d connected with on LinkedIn, and started doing podcasts or Q&A sessions that I’d publish on my blog.

I remember writing about Cem Kaner – a well-known QA leader who I greatly respected and had once quoted in my master’s thesis on measuring software quality. Imagine how surprised and excited I was when he left a comment on MY blog!

I soon was getting other comments from QA and agile experts and feeling elated that these big-name experts and authors were communicating – some even on a personal level – with me … an unknown, unemployed blogger!

I became “real life friends” with Lisa Crispin, who I always admired, and who co-authored what I consider the most comprehensive and well-known books about agile testing.

My blog led to a job, but not the job I’d expected. I was offered a position as the site editor for, and soon was going to agile conferences, networking, interviewing and writing about agile development and software quality for a living.

Though I eventually went back to a QA management job, writing and networking with agile and QA professionals allowed me the best professional development I’ve ever had in my career.

What’s particularly thrilling for me is that many of the agile greats are now my Facebook friends, and I get to know them on a more personal level. Mike Cohn, with his humor and puns, is an absolute favorite.

Besides blogging, there are many other ways to share your knowledge and expertise with others. Volunteer to speak at user groups or events, host a podcast or YouTube channel, train, coach or mentor others who want to learn.

Social media is the ultimate tool in allowing us to learn and master any skill. However, beyond the written word, we have exposure to the minds of great leaders.

Take advantage of this treasure and you’ll soon find that not only will you grow your skills, you’ll also form life-long relationships.

Lessons Learned in Preparing for the PMI-ACP Exam

I happen to be a very good test-taker. When I was young, I thought it might be fun to have a job helping people who were preparing for standardized tests like the SATs.

Though I never had that particular job, now that I’m an agile coach teaching a course that helps people prepare for the PMI-ACP exam, it’s right up my alley. Of course, to qualify to teach that course, I had to first earn the PMI-ACP certification myself.

“No problem!” I thought. I’ve been totally immersed in “everything agile” for years, so it should be a piece of cake to get certified. I filled out the application and had the requisite experience and training, so now I simply needed to take the 120-question test.

The day before I was scheduled to take the test, I got my hands on a couple of sample exams. I’m embarrassed to say that I didn't do very well on them. Even though I thought I knew everything there was to know about agile, apparently I didn’t know how much I didn’t know!

Besides kicking myself for waiting until the day before the test to take the practice exam, I was also annoyed that I didn’t even agree with some of the answers on the practice tests, many of which I felt were really a matter of opinion.

For example, one of the questions on the sample exam was:

"A project retrospective is scheduled to last an entire day. One of the stakeholders asks if they can drop in and drop out throughout the day. What should the retrospective leader tell this stakeholder?

a) Tell the stakeholder full-time attendance is necessary because each part of the retrospective structure builds on the preceding portion.

b) Tell the stakeholder it's okay to drop in and drop out since their feedback is important.

c) Ask the stakeholder to still attend the retrospective and bring their other work with them to do in private.

d) Reschedule the retrospective until every participant's schedule allows for full-day attendance.”

Correct Response: D … Did you guess that?

“Drop-ins slow down the retrospective process; drop-outs send a different, often puzzling message. Set the expectation for full-time attendance as recommended in this answer choice.”
- Esther Derby and Diana Larsen, "Agile Retrospectives," Chapter 9

Wait a minute! Reschedule? Really? This is not a very realistic answer, since rescheduling to suit one stakeholder’s schedule will undoubtedly cause a problem for someone else. Waiting until everyone is available all day is likely to either be unrealistic or cause a long delay.

I had picked answer “A” and I still think that’s closer to “setting the expectation for full-time attendance.” Also, the question asks what the leader should tell the stakeholder, and “D” is the only answer that doesn't tell the stakeholder anything.

This is just one of many examples where the “right” answer was somewhat ambiguous.

I really didn’t have the time or ability to dig into all the answers I disagreed with, so I focused on learning unfamiliar material and memorizing all I could before the test.

Luckily, I passed the exam, which was easier than the sample tests, but still had a number of questions which I felt were not at all black and white. Agile suggests that we don’t assign black-and-white solutions to problems, but consider the context.

I thought many of the questions would be good for discussion, and that even the experts would have differing answers. It would be nice if we could have the answers as well as explanations on why a particular answer was considered “right,” but for now, I’m just happy to have passed despite my lack of preparedness.

PMI provides some tips and a reference list of materials to prepare for the test. They did allow feedback about the questions at the end of the exam.

Overall, I think it might be interesting to have a panel of agile experts (maybe all the people who wrote the books referenced) take the exam. Any question that gets different answers from the experts should be, in my opinion, eliminated or reworked.

In general, I’m not crazy about “certifications,” but I understand their purpose. This is not an easy one to earn and should instill credibility and respect for those who do earn it. On the other hand, I think the test questions need to be better vetted.

Lessons learned:

Don’t wait until the day before the exam to start preparing. There’s a lot more information in the agile reference books than I realized. Don’t depend on PMI-ACP practice exams as your sole resource for studying.

If I hadn’t passed, I’d be very curious to know which questions I’d missed and whether I’d have a chance to contest them. But luckily, I did pass. Taking the exam forced me to study and recognize that there was a lot I didn’t know.

Learning is always a good thing and for that reason, I’m happy to have had the experience. 

Have you taken the PMI-ACP exam? What are your thoughts on it? Let me know in the comments below.

Physical vs. Electronic Task Boards – Which Is Better?

I recently spent a few days on a coaching assignment with a small team that transitioned to agile about a year ago. We started with a retrospective of their agile practices, and I found it interesting that a task board they could physically touch was something the team liked best.

Obviously, agile practices promote the use of a physical task board for several reasons, and this team really was seeing the benefits. Here are some of the reasons they so enjoyed their task board:

-They have fun with it. For example, they each have their own Lego superhero figures, which reside on the cards they are working on. -The physical board is a great “information radiator,” providing visibility and transparency into what everyone is working on without the need to log into a tool. Because this is the only team practicing agile, the task board provides other teams with a little peek into how an agile team operates. -The physical board helps sort out what they're working on in the sprint without them digging through emails, spreadsheets or any other tools. They liked this low-tech approach, which, of course, is what agile methodologies promote.

I found this interesting because personally, I’ve had some issues maintaining a physical task board, and wondered if the very notion was going “out of style.” I’ve often thought electronic boards were preferable because:

-You don’t have to be physically present to see the status of the board (especially useful if you have remote team members or anyone who works from home). -Electronic boards will calculate velocity, burn down and other metrics for you. -You have documentation that will store data about the user stories, which is handy for traceability if similar stories or questions come up. -If you have both physical and electronic boards, you have two different records, which is usually a mistake because of the potential for maintenance and consistency issues.

Because this team chose not to use burn down or burn up charts, they did not have the cumbersome task of manually calculating these numbers or keeping both a physical and electronic board in sync.

Though the team felt good about their physical task board, they weren’t crazy about their stand-up meetings. Because their task board is in a hallway, having the stand-up meeting near it created disruption for others in that area, so they had their stand-ups without the benefit of their task board. 

Also, team members were allowed one weekly work-from-home day, and they chose not to call into their stand-up meeting during those days. Stand-ups often started late and went long. For these reasons, the stand-up meeting rated low in their assessment of the usefulness of their agile practices.

So here’s the solution that was created: In order to keep the benefits of their task board, and address the concerns of their stand-up meeting, the team decided to hold stand-ups by the task board, promising the people sitting close by they would minimize the noise and limit their meetings to 15 minutes.

This change also provided incentive to keep the stand-ups short and focused. If someone is working from home, they answer the stand-up questions via email and have a delegate make the updates on the task board.

The textbooks recommend a physical task board. And the team I highlighted today certainly realized the benefits of it. But, there were definite issues in the stand-up meetings due to not having the task board available. It was rewarding to see the team discuss the different issues and come up with a solution that worked best for them.

Do you prefer physical or electronic task boards? Let me know in the comments below.

Learn from the Agile Skeptics

When I’m teaching a class on agile basics, I like to play a game where I give points to the people who challenge what I’m saying or give examples of when what I’m saying might not always be true.

Not only does it encourage class engagement, it gives people an opportunity to safely disagree.

I embrace those who are skeptical about agile development and encourage them to tell me more. Once they see that I will not become defensive, and in many cases, even agree with their concerns, they are much more open to working at coming up with solutions or at least, a common understanding.

This technique of using opposition to your advantage is one change management pattern that Linda Rising and Mary Lynn Manns describe in their book, "Fearless Change: Patterns for Introducing New Ideas."

When I encounter people who “don’t like agile,” and I ask them why, I would say there are two categories of answers.

The first category has to do with what I’ll call “hype” (i.e., it’s sold as a silver bullet) and the second category has to do with “process” (i.e., we need more planning up front).

Let’s talk first about complaints that fall into the first category – the hype. In the post: How do you convince an agile skeptic? by agile coach Daniel Markham, he says these are the reasons why people are against agile:

Fake success stories Trainers who can't do the work Inflexibility on the part of adherents "Feel good" agile Magic Bullet syndrome Reversal of team dominance Cargo Cult agile Non-answers to questions Conflicting advice Scamsters It's the same, only different Little Gold Star syndrome

Markham does an excellent job of describing these negative perceptions of agile, followed by some basic descriptions and definitions of iterative development, incremental development, Scrum and agile.

In the case of “hype”-like complaints, I think the skeptics make a good point!

The best way to address this type of complaint is with good education and training on Scrum (agile’s most common methodology) and agile (a set of principles and mindset, rather than a prescriptive methodology).

As for “process complaints,” I contend that those complaints are more likely aimed against a poor implementation of Scrum vs. a complaint against agile.

Agile (and Scrum, for that matter) promote the practice of “inspecting and adapting.” So if you have a problem with a process, bring it up, and work as a team to try and improve that process.

A link to a more recent blog post from a skeptic was sent to me the other day on how agile is the new Waterfall. Actually, I’d say the author of this post is more negative than a typical agile skeptic.

He appears to be an “agile hater,” claiming that “agile has become everything that Waterfall was to developers and worse. It is a sheep in wolf’s clothing and I’m going to expose it here today.”

I won’t go through the entire post (which would result in a virtual field day for those of us who like to “learn from the skeptics”) but filter out what appear to be some of the “process concerns”:

“The reality of agile is that you still have immutable decisions made by business people with no real understanding of technology. Those decisions are then forced on to developers.” “Unfortunately, with little or no documentation, now the developer is accountable for the outcome while having little or no authority to create a winning one. This responsibility without authority makes agile even more toxic than Waterfall.” “The addition of the daily “scrum” ensures that anyone who is perceived to be working too slowly (whether this is true or not) is immediately highlighted. This type of “boiler room” atmosphere may work great for a few, but for most it is a source of significant stress and ultimately lower productivity.”

Again, these issues are more likely due to a new Scrum implementation. This author seems to be using “agile” and “Scrum” interchangeably, as many people do, which certainly adds to the confusion.

In fact, the post ends with a suggestion of starting over with minimum process, which the author admits is agile, but says it’s with “a lowercase a agile, not uppercase a agile.”

(Note there is currently no standard on the use of lowercase agile vs. uppercase agile. As a writer, this is frustrating for me, but I digress.)

The author has come up with what he feels are solutions to the above problems, which is great. However, I would suggest that these problems are not experienced by most Scrum teams and his solutions are not appropriate for everyone.

I’d also suggest that when a team is experiencing process issues, they stop, reflect and adapt. It’s not clear whether or not the problems this author experienced were discussed in a retrospective, but had they been, the team may have been able to resolve these issues and continue to improve.

Neither Scrum nor “agile” (upper or lowercase) are going to be perfect or make software development easy. If someone tells you that, challenge them.

Whatever processes you use, the team is bound to encounter problems. Listen to those problems and work as a team to resolve them.

Healthy skepticism is a good thing. Listen to and enlist help from the skeptics in finding solutions in order for your team to continue to learn and grow.

Agile ShuHaRi

ShuHaRi, a term that originated from Japanese martial arts, is often used in agile classes to describe a learning model.

Shu represents the first stage when the student imitates techniques.

Ha represents the second stage when the student understands the underlying principles and theories, and feels comfortable making modifications, keeping the principles and theories in tact.

Ri represents the final and the most innovative stage. The student is creating his own approaches and adapting what he’s learned to his unique circumstances.

When I’m teaching students who are new to agile, I use a cooking analogy, both to describe ShuHaRi and to describe the difference between what it means to “be agile” versus following a methodology, such as Scrum.

I tell the class that agile is like cooking and Scrum is more like a recipe. Agile gives us the manifesto and the 12 principles, but does not provide a step-by-step “cookbook” approach to either project management or developing software.

When we are new cooks, we need to follow a recipe. This is the “Shu” stage of learning to cook.

As we become more familiar with different flavors, we reach the “Ha” stage, feeling comfortable modifying the ingredients to our taste.

Finally, as we become chefs (“Ri”), we create new recipes or maybe write a cookbook ourselves, striving to create a unique and innovative set of recipes or approach to cooking.

If we compare this to agile, when we are new, it’s best to use the more prescriptive approach to following a methodology, such as Scrum. In other words, we need to “follow the recipe” at this stage.

Though agile promotes adaptability and flexibility, when a team is new and still in the “Shu” stage of learning, they are probably better off starting with the recommended “best practices” provided by the experts.

Too many people feel that they will be more agile by not following a recipe or rule book, but that really depends on how experienced the team is.

If you have a bunch of people who are inexperienced cooks who throw a bunch of ingredients together without really understanding the concepts behind cooking, the chances are that your resulting dish is not going to taste that good.

Similarly, inexperienced agile practitioners who pick and choose different agile techniques to follow may end up with a methodology that doesn’t work too well.

It’s really better to at least start with that recipe. However, having the benefit of gathering feedback and constantly adapting and improving allows the team to develop the skills to move to that next learning stage.

Whether it’s cooking, music, art, software development or project management, when we are new, we start the learning process by imitating others.

Over time, we gain the skills to make modifications, and at the highest levels, we create something entirely new.

Agile: Not Just for Software Developers

“Let’s create a backlog for all the things you want to do,” I tell my friend, Joe, trying to convince him to give Scrum a try in helping to manage his ever-growing personal to-do list. “Then we’ll pick the highest priority things and you can focus on those for the next two weeks.”

At the end of those two weeks, Joe had started on a bunch of things, but hadn’t finished much. “I think your ‘stories’ need to be smaller and you need to limit your WIP,” I advise. “Finish some of these before you start on anything new.”

After breaking down some of his bigger stories into more manageable chunks, the next two weeks showed much more progress – and some of the projects that had been on his to-do list for months were finally done! He was an agile convert!

Agile, No Matter What the Situation

There’s something about checking off an item as complete that really gets your endorphins flowing. That was a comment from a student in an Agile Boot Camp I recently taught for a bunch of engineers that were not software developers.

At first, they were very skeptical about using agile, feeling like the concepts really wouldn’t apply (because in their field, they needed to know the entire design up front).

However, the more I described various techniques for creating smaller stories and continually checking in for feedback, the more head nods I got from the class that showed that they could see advantages of working in a more agile manner.

There are certain concepts, such as working collaboratively with customers, breaking tasks up into manageable pieces and continually “inspecting and adapting” that make sense no matter what domain you work in.

I recently wrote an article about personal Scrum giving examples of ways Scrum is being used outside of software development and was especially impressed with the creative use of Scrum in wedding planning by Hannah Kane and Julia Smith in their business venture, Scrum Your Wedding.

The article I wrote generated comments including a reference to the book, "Agile Kids," which promotes the use of agile techniques to empower kids to be in control of their tasks while still respecting parental authority.

The Tools to Manage Anything

Agile concepts and techniques are proven project management and leadership practices that work well both in business and in personal life, regardless of your profession.

You don’t have to be a software developer or techie to jump on the bandwagon. Start by learning some of the terminology and concepts, and then if you want to get some experience, try using the concepts to manage your personal to-do list.

Elicit a friend and work together on some of the tasks. Spend some time after each iteration to host a retrospective so you can “inspect and adapt.”

Mike Cohn describes how he uses Scrum in his personal life using tools like Things and Asana. I’ve used Trello, a free, easy tool that provides a task board that will help you visualize your workflow.

Don’t get too caught up in tools if you’re new to agile, though. Simply using a pen and paper or even notecards or sticky notes is fine and even encouraged in agile circles.

Undoubtedly, as agile techniques continue to become trendy in everyday life, people will start to refer to their “backlog” or suggest they should “time box” an activity or “limit their WIP.” So, why not get ahead of the game?

Do you use agile techniques in your personal life or to manage your own to-do list? What are creative ways you’ve seen agile used outside of software development?

Large-Scale Agile: SAFe and DAD More Friends Than Competitors

One criticism of agile has been that it’s tough to scale. In answer to that, new methodologies and frameworks have cropped up designed to better handle enterprise, large-scale projects, taking into account agile principles.

I recently took a Scaled Agile Framework (SAFe) class and earned my SAFe Program Consultant (SPC) certification from Dean Leffingwell himself! It turns out, Mark Lines, co-author with Scott Ambler of the "Disciplined Agile Delivery" (DAD) book was also in the class. What an awesome opportunity it was for the class to learn about these two frameworks from the true experts!

Both Dean (on the right in the picture) and Mark (on the left) acknowledged that SAFe and DAD were not competitors. SAFe is more prescriptive and primarily uses Scrum at the team level, and extends the framework to outline roles, ceremonies and artifacts at the program and portfolio levels using a variety of lean and agile concepts.

DAD is described more as a process framework that helps users determine a methodology that might be right for their situation. I reached out to Scott Ambler via email, and he described the difference this way:

“In many ways SAFe is an instance of DA. Where disciplined agile provides choices, SAFe instead makes a collection of choices for you and shows how that subset of DA works together. As long as you’re in a situation where those choices make sense, then SAFe can work for you. If your context is different, then you need to make a different collection of choices. If your organization has adopted SAFe, then it should take a very close look at disciplined agile for tailoring advice to help you to evolve SAFe into something that will fit well in your environment.”

Both SAFe and DA use many techniques that originated from various methodologies. In fact, so many agile methodologies mix and match techniques that most people don’t even know where they originated. I only learned recently that user stories originated with XP. I’ve seen them used so often in Scrum that I assumed they originated there; but, in fact, the Scrum Guide doesn’t even mention user stories.

Though many people act as though the various methodologies are in competition with one another, they actually are quite complementary. Even waterfall and agile can play nicely together!

Scrum has become such a popular agile methodology, that many people use the terms agile and Scrum as synonyms. This happens when one brand seems to have cornered the market. When I worked at IBM, management warned us that we were not to use the term “Xerox” when making a copy because IBM made a copier, too. And I’m sure Microsoft is not crazy that people suggest “Googling” rather than “Binging.”

So while Scrum is not the only agile methodology, its popularity is so prevalent that it’s a good starting ground for those new to agile. Certainly, learning the terminology and concepts associated with Scrum will provide a good basis for any agile training.

True, learning agile can be a bit overwhelming because there are a variety of methodologies and techniques that fall under the agile umbrella. These are not competitors in which an organization must choose one right way of operating, but more a toolkit with choices.

Though Scrum started by addressing the needs of small cross-functional teams, it can be extended, and frameworks such as SAFe and DAD are emerging that help further the agile toolkit for the enterprise.