Tag Archives: agile

It is a well-documented fact that I love Agile. I blog about it, write books about it, make my kids do their chores in an Agile way… But the realities of an Agile implementation are often full of struggles and angst.

In this blog, we will address the 5 Common Frustrations of Agile teams with some tips on how to avoid.

Great Idea Syndrome or Critical Client Request

These are the ideas that come up, usually from the executive team, that can disrupt a sprint in progress. What can you do?

Have the Product Owner be the ‘interceptor’ and immediately begin flushing out requirements without involving the developers.

Be very transparent with the Executives about the current work in progress and its priority. Sometimes that will diffuse the urgency of the new request.

If it keeps happening, create a Kanban team (or just identify a single developer) that doesn’t have commitments in the current sprint that can take the one-off requests without bothering the dedicated developers.

Commitments aren’t honored

The sprint comes to an end and tickets/tasks/stories just roll to the next sprint. This is often accompanied by loads of excuses but it is demoralizing for the team and devalues the entire Agile process. What can you do?

Work on the definition of done. Does “done” mean tested and ready to deploy? (It should). If so, you might not be leaving enough time for QA so you might have to back up the ‘code complete’ timeline.

Remove distractions and disruptions. If the team is getting hit with new work, then that needs to be removed (see above).

Make sure the team understands and agrees to what ‘commitment’ means. This might start with a working agreement. Often, they aren’t aware that making a commitment means you will get it done. If they think it is okay for a story or task to roll to the next sprint, then something is missing in the interpretation of Agile and its commitments.

Check your estimating. One of the biggest problems associated with missing sprint commitments is the underestimation of how long it will take to finish a story. This is very common with Scrum teams so it is just something you work to continuously improve. Some sprints will be better than others, but taking the time to learn from and refine estimation problems will definitely help in making future commitments.

One of the foundational tools for Agile is Working Agreements. This blog will explore three uses for this power concept.

First, what is a working agreement?

A working agreement is a document of the values and behaviors that apply to a team. It facilitates great discussion about what will work for all team members. For software development teams, it could address topics such as after-hours availability, meeting etiquette, team member attitudes on interruptions, philosophical positions on accountability and more. Working agreements are powerful because they are crafted by the team, for the team. This is not management dictating terms; it is the team coming together to decide what works best for them. No two working agreements should be the same, and as team members change or teams evolve, working agreements should be modified to stay current.

Now that we know what they are, how can they help build teamwork in even the most dysfunctional team?

Facilitate Difficult but Necessary Conversations

When developing a working agreement, the team is gathered in a relaxed setting where difficult conversations can arise without drama and theatrics. Let’s talk about whether starting meetings on time is important to us. If so, we can add it to the working agreement. If there is a team member who is chronically late, then this discussion isn’t about singling them out, but rather figuring out what works best for all team members. Agile is a powerful way to do business. It is not a magic pill and it will not solve all of your problems – but it will bring them to the surface where they can be positively and proactively addressed. A working agreement is one of the tools to drive that critical conversation.

Do you want to create winning teams? Or improve already effective teams? Agile can help – regardless of what department you are in. As background, Agile is a software development methodology that uses practical tools and concepts to empower people to be more productive. Here are three tools that you can start using immediately to enhance teamwork and trust in your organization.

Working Agreement

What is it?

A working agreement is a document of the values and behaviors that your team defines for how they will work together. It is powerful because it is crafted by the team, for the team (not by management). It facilitates great discussion about what will work for all team members. It could address topics such as after-hours availability, meeting etiquette, team member attitudes on interruptions, philosophical positions on accountability and more.

How to get started:

The easiest way to introduce a working agreement at the office is before a long meeting. The meeting could be a few hours or a few days, but long durations tend to bring out the worst in all of us. Ask for five minutes at the start of the meeting to document a working agreement. Ask everyone to define the appropriate behaviors for the meeting. You may have to prompt the group with provocative questions like “Are smartphones allowed? Who is taking meeting minutes? When are break times? If everyone is not back after a break, does the meeting commence, or do we wait?” With a little prompting, a healthy discussion should take place. Write down the results of the discussion and keep the working agreement displayed throughout the meeting. If anyone violates a tenet of the working agreement, any team member can gently point out the discrepancy and the meeting can continue. This simple introduction to working agreements will allow people to become familiar with the practice and then you can apply it more broadly to project teams.

By most accounts, my first experience with an Agile roll-out (specifically Scrum) was quite successful. We went from 3 Scrum teams to 12, we increased employee job satisfaction measurably and we delivered faster and more accurately than ever before. We rolled out six products in less than 3 years and that is a remarkable feat. One that I am certain we could not have achieved without moving to – and embracing – Agile. So how did we do it? What made our efforts successful when many other companies have struggled or failed? Here are my perspectives on how we found success.

Image Source: http://obdc.com/consulting-for-business-success/

Executive Sponsorship

Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ Without that vision and dedication to making it happen, it would have been really hard to move out of Waterfall, which had been ingrained into the workflows, processes and the very culture of an organization. But top-down isn’t enough. You also have to have a group of developers that are eager to make the change. Like most things, you cannot force people to change their behaviors if they are completely unwilling participants. At our company, we were very lucky. We had incredibly talented developers across the organization who were anxious to try new ideas and see how we could innovate. That bottoms-up enthusiasm combined with the top-down dedication gave the movement to Agile a fighting chance.

As introduced in the first blog, prioritization is difficult. The first and most important question is “should we do this at all?” Once you determine that an effort is worth doing, we have to figure out where it falls relative to the other things in the queue. There are a number of tools that we can use in this effort.

MoSCoW

The first tool in our arsenal is from Dynamic System Development Method (DSDM) and it is an acronym for Must have, Should have, Could have, Want. The technical definition for each category is as follows:

Must have: all features classified in this group must be implemented, and if they are not delivered, the system would simply not work.

Should have: features of this priority are important but can be omitted if time or resources constraints appear.

Could have: these features enhance the system with greater functionality, but the timeliness of their delivery is not critical.

Want to have: these features serve only a limited group of users and do not drive the same amount of business value as the preceding items.

To put MoSCoW in action, we pull a reference from our book, Introduction to Agile Methods. In this example, we are looking at the payment methods that could be offered on a new eCommerce site.

As a Product Manager and an Agile Enthusiast, I have lots of conversations about prioritization. It is really tricky. Well, that’s not always true. If you really only have one thing to work on, then I guess it’s easy. For the rest of us that live in the real world, we have to balance multiple number one initiatives in a way that will deliver the most value to the business. This is a first in a blog series about Prioritization.

The First Question

The very first question that should always be asked when considering something for prioritization is – Should we do this at all? People are too often moving too fast and trying to be responsive to the point that sometimes we stop thinking. One of my mentors had a saying: “This is top of mind, not top of list.” I love that. I first heard this when he called me after just having talked to an important client about a feature they wanted. He was excited and it was a good idea. I asked him if he felt like we should reshuffle our priorities and execute on this newly introduced concept. He paused and took a moment to really think through my question. And then he responded with the now often quoted “Top of mind, not top of list.” That is a fantastic barometer to keep in mind when you have a flash of brillance. It might just be a flash and you need to stick to your existing priority list. Bright, shiny objects can come into view, but they do not always warranted our immediate attention.

Here is another guest blog from my co-author on the Introduction to Agile Methods textbook, Dr. Sondra Ashmore (@sondra1130). This is her recap of the Agile 2014 Conference in Orlando, Florida.

Agile 2014 Recap

Sondra Ashmore participating in 3D Pair Programming Session.

I think I have finally recovered from the excitement of Agile 2014 that took place in the fun and sun of Orlando, Florida this year. I found it very invigorating to spend the week with nearly 2000 fellow Agile enthusiasts from around the world.

When I initially signed up for the conference, I decided to fill my schedule with a variety of different sessions from the wacky (Agile Karaoke) to the more traditional (Agile Enterprise – Are You Ready?) and finally some research sessions to satisfy my academic side. I was glad I did because it helped me get a general feel for the current trends in Agile and forced me to look at my world in a new way.

The fact that I can title this blog “Lessons from an Author” is both amazing and surreal. You see, my first book was just published so I guess I can officially say that I am an author. (Buy it here!) Holding the book in my hands led me to reflect on the last 18 months and the journey that my co-author, Sondra Ashmore, and I have been on. For what they are worth, here are the lessons that I have learned along the way.

Persistence Required

When writing a book, or doing any meaningful and challenging undertaking, you must have persistence. This is obvious, I know, but let me share the backstory. There were two chapter in our Agile textbook that were particularly difficult – the chapter on roles and the one on culture. Not that we didn’t have plenty of content, that was never the problem. It was trying to figure out a way to convey the information in a logical and cohesive fashion. Each chapter was re-written nearly from scratch three times. By the time you are writing a chapter for the third time, it is easy to get frustrated, depressed, aggravated, annoyed (can you tell that the memories are still fresh??) and a whole host of other emotions. This is when you need someone to pull you back to the surface. In my case, I was lucky to have Sondra. In my time of doubt, Sondra reminded me that this is the time and circumstances that separates published authors from those with unpublished work sitting in a drawer. It is persistence. Pure and simple. There are lots of great writers out there. But persistence is the distinguishing trait for true authors.

For the final blog post in our series about our upcoming book, Introduction to Agile Methods, we are going tackle the cultural impacts of an Agile implementation. Agile is a simple set of concepts to understand (once you read the book, of course) but that doesn’t mean it is easy to implement. It can be challenging for organizations to adopt principles like self-organizing teams, continuous improvement and frequent delivery. This chapter examines creating an Agile culture from the perspectives of a team member, manager and an executive.

Learning Objectives

Understand organizational culture and why it matters in an Agile implementation

Dive into ways things might be different in an Agile organization from a developer, manager, and executive viewpoint

Look at successes and failures in behaviors to see the cultural impacts

Understand how the Agile principles drive different behaviors in an organization

Explore how an Agile workplace differs for managers and the ways that they must change with regard to teamwork, trust, and transparency

Review the role of executives and how their behavior can position an Agile transformation for success with executive alignment, respecting priorities, creating supportive environments for the teams, and driving the right behaviors with metrics

There is so much great content in this chapter, it is hard to pick one excerpt to spotlight. We chose the executive viewpoint and how important it is for the executive sponsor to embrace the change and provide consistent leadership.

Staying the Course

An Agile transformation is challenging for most organizations. Some command and control managers will fight the change, offering dire predictions of failed projects as examples of why this is a bad idea. Developers may not embrace the increased accountability and transparency, and some may choose to leave the organization. There are new expenses in the form of seating arrangements, training, and Agile tools that may stress the budget. Agile transformations also have a history of bringing chronic issues that the organization has ignored for years to the surface where they must be confronted. All of these are reasons why an executive might abandon the effort and simply revert to what is comfortable (but ineffective). Any change worth making is going to require effort, and Agile is no different. The strong Agile executive will work through these issues without wavering on the commitment to Agile.