Tag Archives: scrum
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.
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.
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.
We are an Agile family. Some of our processes work better than others, in typical Agile fashion, but we aspire to continously learn and improve. Our latest family problem is chores. We have three teenagers and determining what is fair and finding a common “definition of done” is quite challenging, filled with all kinds of wonderful teenage angst. Our activities tonight are attempting to bring clarity.
Step 1: Define chores with a Definition of Done
First, we sat down with index cards and listed out the chores, one per page. Truthfully, I did this mostly on my own but I read them all to the kids to make sure they agreed.
The final list was as follows:
- Empty kitchen trash and take out recycling whenever full (2)
- Empty all trash cans, take trash to curb on Tuesday morning, retrieve Tuesday night (1)
- Vacuum tile floors upstairs – baths and laundry room (we have a dog that sheds) twice a week (5)
- Vacuum upstairs carpets once a week (8)
- Vacuum downstairs floors once a week (8)
- Empty full dishwasher whenever clean (5)
- Clean off counters, tables, put shoes in closets nightly (5)
- Do dinner dishes and put away left-overs nightly, not pots and pans (8)
- Wash pots and pans, dry them and put them away by 9:00 a.m. the next morning (13)
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.
- 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
- Investigate the healthy team dynamics of self-organization teams, continuous improvement, frequent delivery, effective seating arrangements, incorporating virtual resources, and adapting to the changing environment
- 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.
One of the amazing things about co-authoring this Agile textbook (Introduction to Agile Methods) with Sondra Ashmore has been the opportunity to learn new things and research other methodologies. For our excerpt from Chapter 8, Tracking and Reporting, I had the opportunity to research Feature Driven Development (FDD) and a great concept called Parking Lots. Here are the Learning Objectives for this chapter and more on FDD Parking Lots.
- Understand Kanban, its effectiveness, and when it is used
- Learn the definition of work in progress (WIP) limits and how they can identify bottlenecks in processes
- Explore different tracking mechanisms used in XP, Scrum, Lean, DSDM, and Crystal
- Understand burn charts, both burn-up for release management and burn-down for sprint tracking
- Examine feature-driven development (FDD) parking lots and how they assist in tracking large and complex projects
- Learn the different strategies for tracking quality through an iteration
- Understand the importance of meetings in tracking progress and course correcting
- Learn the purpose and desired outcome for each meeting—the daily stand-up, the Sprint review, and the retrospective
- Consider the metrics for measuring the success of Agile projects
Feature-Driven Development (FDD) Parking Lots
FDD incorporates an excellent way to track progress on larger projects where many activities are contributing to a cohesive whole. For our Cayman Design project, we want to create and sell weather-related calendars to customers; this is a large departure from the other features in our weather app because we have to consider inventory, shipping, and payment details. An example of an FDD parking lot might look like what is shown in Figure 8.7.
This tells us that the feature “Collect Customer Information” consists of seven stories totaling 32 points. At this moment, we are 75% complete, and the feature is needed by August 2014. The color on the story can indicate its health, this particular story being yellow, meaning it is in jeopardy. Although this is an interesting depiction of information, it is not necessarily more valuable than any of the other Agile tools we have discussed—that is, until you add many other components, and then the picture painted by the FDD parking lot is incredibly useful (see Figure 8.8).
In the next edition of this blog series highlighting excerpts from our upcoming book, we will tackle the tricky subject of Technical Debt. To be honest, I had a hard time choosing a single topic from this chapter because there are so many great topics covered – Definition of Done, Planning Poker, Value Stream Mapping, the Kano Model, Velocity, the XP Planning Game – and much more in this chapter on Grooming and Planning. And it includes an interview with none other than Mike Cohn! If this post, or any of the previous ones on Roles or Requirements or our guest blog from co-author Sondra Ashmore inspire you to want to purchase the book, please visit Amazon and search on Introduction to Agile Methods.
Back to Planning and Grooming, here are the Learning Objectives for the chapter.
- Understand the elements of a product backlog and what traits lead to the strongest deliverables
- Dive into prioritization and learn different methods for understanding what is the most important feature or item to work on
- Explore estimation and the different practices and measures that are used today
- Understand story points and planning poker as ways to discern the level of effort and complexity of the user stories/requirements
- Learn the other inputs that affect the planning process, such as team velocity, definition of “done,” technical debt, and bugs/defects
- Evaluate Sprint planning and the XP planning game to learn how commitments are made and work is planned
- See how maintenance work can be incorporated into Agile teams
- Review the triple constraints model and how it is handled within the Agile framework
This is the second in a series of blogs about our upcoming textbook called Introduction to Agile Methods that I have written with Sondra Ashmore. The first blog spotlighted Roles and our second post was a guest blog by Sondra on Agile in Academics. I hope these blogs inspire you to want to read the whole book! Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan. The chapter spotlight for this post concerns Requirements and how they are approached very differently in Agile, as opposed to Waterfall. Within Agile, the terms around requirements include User Stories, Epics, Acceptance Criteria, Personas, Release Management and much more. The excerpt that I have chosen to share here addresses a particularly challenging aspect of managing requirements and priorities – Customer Specific Code Requests. First, here are the learning objectives for the chapter.
- Recognize the differences between Agile and Waterfall with regard to requirements gathering and documentation
- Understand the format used within Scrum for user stories, including epics and acceptance criteria
- Explore several examples of how user stories are broken down from epics to child user stories and how acceptance criteria add important details to the story
- Learn how the other methodologies differ from Scrum in their terminology and practices
- Examine how requirements can be enhanced by using personas or engaging User Experience (UX) designers to better understand potential system users
- Understand how user stories and Agile development efforts map into a marketplace driven by consumer demands and customer-specific development requests
- Value the importance of communication and transparency when it comes to requirement specifications and priorities
- Explore Lean software development and the Lean start-up concepts and how they influence the product development process
We are getting closer to the publication of the Agile textbook that I have co-authored with Sondra Ashmore. It is such an exciting time for us and I want to use this blog series to highlight chapters from the book. I hope you enjoy this so much that you want to order the book. Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan.
One of the chapters that I was responsible for addresses the roles within Agile and specifically Scrum teams. Here are the chapter learning objectives as well as an excerpt from the section about Product Owners, something I am very passionate about.
- Understand the roles in Scrum with their specific responsibilities—product owner, Scrum master, and team
- Identify the attributes and personality types that are most successful in the various roles
- Learn the Agile definitions of “chickens” and “pigs”
- See how extended team members interact with the team
- Compare and contrast the roles in Scrum and the other methodologies
- Walk through practical examples of how the roles are filled in different-sized organizations
Product Ownership – Breadth
Another nuance of the product owner role is the breadth of his or her ownership. Does one product owner manage multiple products? Or is one product so big that it requires multiple product owners? Both of these situations are common in the workplace where teams are thin and expectations are high.
To examine the first instance, what are the advantages and disadvantages of having one product owner responsible for multiple products? The biggest risk factor is time and attention. Can the product owner devote adequate time to every product that he or she is responsible for? Does this person have the necessary depth of understanding to truly collaborate with IT on the best solutions? It is a risk, but certainly one that can be overcome.
In the instance where the product is large enough to have multiple product owners, there is a chance that the priorities will not align. Related to the previous reference of business value, if one product owner wants to expand to new cities to attract new users but another product owner places top priority on improving the processing speed, then you can run into conflicts. However, one of the core tenets of Agile is collaboration, which includes collaboration between product owners. Product owners need to be in communication with each other to clearly articulate the best plan for all groups—knowing that at any given time, one group’s needs will take precedence over another’s.
Even if you have a single product owner for every product, that does not mean that things are easy. Between systems there are interactions, and to create a new feature or make a modification, the product owner may need to consider dependencies.
Introducing Agile into your software development projects, or other organizations in your company or into your life has produced
wonderful, empowering results for many people – myself included. I often get asked “What is Agile, in simple terms?” Here is my attempt to boil it down to 100 words which will hopefully resonate for everyone, regardless of your background.
Agile is an approach to problem solving. We tackle big projects by breaking them down into small, deliverable chunks. After each chunk is completed, we inspect it and adjust based on what we learn. We prioritize each chunk based on its value, to ensure we work on the most important stuff first. We work as a team where smart people get together face-to-face to brainstorm solutions to complex problems. We succeed as a team and measure our progress to immediately address any roadblocks. We strive to deliver more chunks with higher quality and clear value on a frequent, sustainable basis.
What do you think? What is missing? Does that make sense to people who aren’t part of this movement? I would love to hear what you think.
I committed this year to write 52 blogs and I did it! There are 16 on my previous employers website and 36 on www.runyanconsulting.com. As I look back and review and reflect on the posts, here are my favorites.
Product Management Blogs
I am very passionate about Product Management and I think it is sometimes an undervalued skill set. Where I have a chance, I always try to share the strategic and practical benefits that come from having great product management resources. This year, I wrote a five part series about how to Launch a Product and recently completed a 3 part series on how to sunset or decommission a product.
I am equally passionate about Agile because I have seen how it can improve people’s job satisfaction and raise the level of productivity and effectiveness for the whole organization. This category was harder to choose my favorites, so I came up with four. First, there was a series on creating an Agile Culture and what it really means for management. This series generated some controversy, which I love because it means we are talking about important things. Next, I am surprised that many organizations are not familiar with Fist of Five. We use the Agile technique all the time and it is a difference maker in driving productive conversations. Many organizations also struggle with how to incorporate Agile into the day-to-day business, so I offered three options for incorporating bugs and maintenance into your Agile teams. Finally, I am a big believer in the sacredness of the Sprint and I believe that organizations that are disciplined enough to honor a sprint commitment will typically be more successful than those who are loosey-goosey with the guidelines.
Finally, I care deeply about leadership and family so some of my blogs were dedicated to those topics. One that has been particularly fun is documenting our evolution to an Agile Family. We have learned (and laughed) a lot together. Also, I spent some time really thinking about Innovation and what drives an innovative spirit in some people but not others. This particular blog might be my favorite of the year.
I hope you have enjoyed some of these blogs and maybe learned something new. I know that I have learned with each post and I am grateful to have the opportunity to continue growing and exploring new ideas. What is in store for 2014? Who knows for sure, but it is going to be a great year!