We talk about how change is happening faster than ever, but that doesn’t mean we need to push change via massive, top-to-bottom initiatives. We see it happening in far more dynamic ways, and so does Dan Pink, one of our exciting RallyON!™ 2015 keynote speakers.
Dan’s presentation, “The Cascade Effect: How Small Wins Can Transform Your Organization,” will cover the complicated nature of change, how it really happens in an organization, and why small increments can have a big impact — especially when it comes to delivering at the new pace of change.
Dan Pink is a recognized author of five provocative books –– including best-sellers in the New York Times –– but his influence extends well beyond his writing. As a speaker, he focuses on behavioral science and has delivered more than 1,000 lectures. Dan’s TED Talk, “The Puzzle of Motivation,” has garnered more than 13-million views.
Don’t miss this opportunity to think differently about how you can affect change within your organization and beyond. Register now for the RallyON 2015 Agile conference — three days of learning, inspiration, and fun with your peers and some of the brightest minds in the industry. Explore our agenda to view everything happening and you can even drill down by track to find the specific sessions that interest you most.
Hope to see you in Phoenix, June 15–17.Morgan Campbell
The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.
Product backlog refinement—sometimes called product backlog grooming in reference to keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.
During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog. The team is given a chance to ask the questions that would normally arise during sprint planning:
- What should we do if the user enters invalid data here?
- Are all users allowed to access this part of the system?
- What happens if…?
By asking these questions earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately.
If those questions were asked for the first time in sprint planning, and too many could not be answered, it might be unnecessary to put a high-priority product backlog item aside and not work on it during the sprint.
These questions do not need to be fully resolved in a backlog refinement meeting. Rather, the product owner needs only to address them just enough so that the team feels confident that the story can be adequately discussed during the coming planning meeting.
Backlog refinement in that sense is really a checkpoint rather than an effort to fully resolve issues.
I like to hold the product backlog refinement meetings three days before the end of the current sprint. This gives the product owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint are more suited to their cadence, and that is, of course, fine.
Unlike other Scrum meetings, I do not think the product backlog refinement meeting requires the participation of the whole team.
If you think about a whole team meeting three days before the end of the sprint, there is likely to be someone who will be frantically busy—someone who, if forced to attend one more meeting, may have to work late to finish the work of the sprint.
I’d prefer to conduct the meeting without such team members. As long as the same team members don’t miss the meeting each sprint, I think it’s fine to conduct backlog refinement meetings with about half the team plus the product owner and ScrumMaster.
It’s all too easy to take it a little bit easier during the summer, so we created a list of agile books to keep you on your toes.
Whether you read them at the beach on vacation or the back porch while the kids are at camp, you can rest assured that your agile practice will be a little bit better this fall.
We live in a world that is broken. For those who believe that there must be a more efficient way for people to get things done, here from Scrum pioneer Jeff Sutherland is a brilliantly discursive, thought-provoking book about the management process that is changing the way we live.
In this book you’ll journey to Scrum’s front lines where Jeff’s system of deep accountability, team interaction, and constant iterative improvement is, among other feats, bringing the FBI into the 21st century, perfecting the design of an affordable 140 mile per hour/100 mile per gallon car, helping NPR report fast-moving action in the Middle East, changing the way pharmacists interact with patients, reducing poverty in the Third World, and even helping people plan their weddings and accomplish weekend chores.
Woven with insights from martial arts, judicial decision making, advanced aerial combat, robotics, and many other disciplines, Scrum is consistently riveting. But the most important reason to read this book is that it may just help you achieve what others consider unachievable – whether it be inventing a trailblazing technology, devising a new system of education, pioneering a way to feed the hungry, or, closer to home, a building a foundation for your family to thrive and prosper.
The Project Management Profession is beginning to go through rapid and profound transformation due to the widespread adoption of agile methodologies. Those changes are likely to dramatically change the role of project managers in many environments as we have known them and raise the bar for the entire project management profession; however, we are in the early stages of that transformation and there is a lot of confusion about the impact it has on project managers:
- There are many stereotypes and misconceptions that exist about both Agile and traditional plan-driven project management
- Agile and traditional project management principles and practices are treated as separate and independent domains of knowledge with little or no integration between the two and sometimes seen as in conflict with each other
- Agile and “Waterfall” are thought of as two binary, mutually-exclusive choices and companies sometimes try to force-fit their business and projects to one of those extremes when the right solution is to fit the approach to the project
It’s no wonder that many Project Managers might be confused by all of this! This book will help project managers unravel a lot of the confusion that exists; develop a totally new perspective to see Agile and traditional plan-driven project management principles and practices in a new light as complementary to each other rather than competitive; and learn to develop an adaptive approach to blend those principles and practices together in the right proportions to fit any situation.
Scaled Agile Framework (SAFe) Distilled:
A Practical Guide to Scaling Agile in the Enterprise
By Richard Knaster and Dean Leffingwell
Today, companies know they must adapt quickly or die. They are increasingly seeking to adapt by using agile principles and practices – but many are still changing too slowly, and can’t sustain change. Fortunately, a growing number of enterprises have found a far more effective solution: the Scaled Agile Framework (SAFe).
SAFe changes the game by integrating Agile, Lean and product development flow thinking with a new operating model that successfully coordinate works at all levels: team, program, and portfolio. SAFe helps managers learn to become lean-thinking leaders, working with teams to continuously improve their systems, and create environments where everyone flourishes.
In Scaled Agile Framework (SAFe) Distilled, two SAFe pioneers show software practitioners how to use achieve higher productivity, improve the quality of their software processes, and bridge the divide between executives, managers and practitioners – aligning everyone towards common goals and objectives. If you want to scale and sustain agile in the enterprise, SAFe can get you there. Scaled Agile Framework (SAFe) Distilled will help you launch it, quickly earn value from it, and grow its value with every new project.
*Book description from Amazon
Agile Change Management:
A Practical Framework for Successful Change Planning and Implementation
By Melanie Franklin
The concept of agile working has been adopted by many organizations that recognize the need to respond quickly and easily to new opportunities in a world of complex and continuous change.
Agile Change Management offers best practice advice for planning and implementing change projects. Concrete tools help deliver projects successfully and realize benefits earlier on in the process.
By emphasizing and encouraging collaborative practices, the book illustrates how to build trust, influence and motivate others, and create a roadmap that outlines all the processes, activities and information needed to manage any type of change initiative. With advice for creating the right environment for change the book explains: who should be involved at each stage in the life style cycle, what tasks need to be completed at each stage, the concept of change in both large scale transformational programs and micro-level business projects, and the needs and benefits behind change strategies.
Along with a practical toolkit of materials available both online and in the book, Agile Change Management is essential reading for anyone who wants to develop the competencies of an effective change manager working in any project or program.
This book is certainly about software development management, but it is also a book about business. Managers can no longer afford to discuss these two topics independently. This book is meant to eliminate the seat-of-the-pants intuition and rough approximations that have been far too prevalent in software development management. The growing popularity of agile methods has shown that a healthy balance between strict process and individual flexibility can be achieved.
David Anderson takes it a step farther, and explains how the healthy balance of agility can help businesses become more profitable. The result is a book that will allow managers to foster teams that produce better software, less expensively, on time, and with fewer defects.
If you have tried to implement Agile in your organization, you have probably learned a lot about development practices, teamwork, processes and tools, but too little about how to manage such an organization. Yet managerial support is often the biggest impediment to successfully adopting Agile, and limiting your Agile efforts to those of the development teams while doing the same old-style management will dramatically limit the ability of your organization to reach the next Agile level.
Ángel Medinilla will provide you with a comprehensive understanding of what Agile means to an organization and the manager’s role in such an environment, i.e., how to manage, lead and motivate self-organizing teams and how to create an Agile corporate culture. Based on his background as a “veteran” Agile consultant for companies of all sizes, he delivers insights and experiences, points out possible pitfalls, presents practical approaches and possible scenarios, also including detailed suggestions for further reading.
If you are a manager, team leader, evangelist, change agent (or whatever nice title) and if you want to push Agile further in your organization, then this is your book.
Discover how to coach your team to become more Agile. Agile Coaching de-mystifies agile practices – it’s a practical guide to creating strong agile teams. Packed with useful tips from practicing agile coaches Rachel Davies and Liz Sedley, this book gives you coaching tools that you can apply whether you are a project manager, a technical lead, or working in a software team.
To lead change, you need to expand your toolkit, and this book gives you the tools you need to make the transition from agile practitioner to agile coach.
Agile Coaching is all about working with people to create great agile teams. You’ll learn how to build a team that produces great software and has fun doing it. In the process, you’ll grow a team that’s self-sufficient and skillful.
This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software. You’ll find chapters dedicated to introducing Test-Driven Development, designing retrospectives, and making progress visible.
Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In this book, Agile Alliance cofounder Mike Cohn discusses the philosophy of agile estimating and planning and shows you exactly how to get the job done, with real-world examples and case studies.
Concepts are clearly illustrated and readers are guided, step by step, toward how to answer the following questions: What will we build? How big will it be? When must it be done? How much can I really complete by then? You will first learn what makes a good plan-and then what makes it agile.
Using the techniques in Agile Estimating and Planning, you can stay agile from start to finish, saving time, conserving resources, and accomplishing more. Highlights include:
- Why conventional prescriptive planning fails and why agile planning works
- How to estimate feature size using story points and ideal days—and when to use each
- How and when to re-estimate
- How to prioritize features using both financial and nonfinancial approaches
- How to split large features into smaller, more manageable ones
- How to plan iterations and predict your team’s initial rate of progress
- How to schedule projects that have unusually high uncertainty or schedule-related risk
- How to estimate projects that will be worked on by multiple teams
Agile development methodologies may have started life in IT, but their widespread and continuing adoption means there are many practitioners outside of IT – including designers – who need to change their thinking and adapt their practices. This is the missing book about agile that shows how designers, product managers, and development teams can integrate experience design into lean and agile product development. It equips you with tools, techniques and a framework for designing great experiences using agile methods so you can deliver timely products that are technically feasible, profitable for the business, and desirable from an end-customer perspective.
This book will help you:
- Successfully integrate your design process on an agile project and feel like part of the agile team
- Do good design faster by doing just enough, just in time
- Use design methods from disciplines such as design thinking, customer-centered design, product design, and service design
- Create successful digital products by considering the needs of the end-customer, the business, and technology
- Understand the next wave of thinking about continuous design and continuous delivery
*Book description from Amazon
Agile Project Management with Scrum (Developer Best Practices)
By Ken Schwaber
The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But Scrum’s simplicity itself—its lack of prescription—can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and failures—culled from his years of experience coaching companies in agile project management. Through them, you’ll understand how to use Scrum to solve complex problems and drive better results—delivering more valuable software faster.
Gain the foundation in Scrum theory—and practice—you need to:
- Rein in even the most complex, unwieldy projects
- Effectively manage unknown or changing product requirements
- Simplify the chain of command with self-managing development teams
- Receive clearer specifications—and feedback—from customers
- Greatly reduce project planning time and required tools
- Build—and release—products in 30-day cycles so clients get deliverables earlier
- Avoid missteps by regularly inspecting, reporting on, and fine-tuning projects
- Support multiple teams working on a large-scale project from many geographic locations
- Maximize return on investment!
Whether you’re brand new to agile or been practicing for years, there’s something for everyone on this list of summer agile reading. I hope the list has inspired you to continue your agile advancement this summer.
What other books would you recommend?
I have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public.
I find it difficult to release books in progress. The in-progress part challenges my perfection rules. I also know that some of you who want this book will wait until it’s done, or worse, available in paper.
However, since this is an agile and lean book, it seems nuts to not release it, even though it is not quite done.
If you get the book, please send me comments about what confused you, what you thought was crazy, and anything else.
Thanks so much!
In case you don’t remember the crazy gold rush days of the first dotcom boom, let’s just say that this was a defining image of the times:
At the time you could land a well paying job at pretty much any dotcom with no more than some basic HTML skills and a willingness to learn. A wave of people swept in and made up a large part of the dotcom workforce. Having a background actually programming was really nice to have, but became almost an afterthought as VCs helped push the rush to bring in warm bodies. If you were in another field at the time and wanted to try out life as a developer, project manager, tester, system admin it was a great time to jump in. There was low risk and plenty of reward.
I worked for a director who had been a bartender until 1999. On a project in 2000 one team had a former translator, an office administrator, and a lawyer. All of them had bootstrapped up on books and built a few static HTML sites before they found their first jobs as developers.
I noticed early on that the talent pool had completely dried up when I opened up an office for a dotcom in 2000 in Las Vegas. Our main office was in SF and I was amazed at the number of hires they’d made that really didn’t have any coding skills. Vegas at the time had a pool of solid developers, but we’re not Silicon Valley and the hometown university is UNLV. Still on average we were able to get better developers typically with real experience. I remember my first time visiting SF in 2000 and noting that 90% of all the billboards in the city were advertising doctors, many focused on recruiting. I’d never seen anything like it.
The bar was almost absurdly low for developer in the dotcom boom. This time the bar has moved up a bit. Now the default entry into the field is a Code Academy or Dev Bootcamp experience. Having survived the dotcom boom and bust I think it’s a good thing that the really junior dev coming from non-science or engineering backgrounds actually has done some real coding before starting their first job.
We’ve dipped our toes into these waters in the past year hiring two junior devs who had gone through dev bootcamps. We’ve been pleasantly surprised by several things that we didn’t get from junior developers in the dotcom days:
- They have pair programming experience
- They actually write unit tests without prodding or coaxing
- They understand that they’re on a steep learning curve and embrace it
- They don’t have a lot of bad ingrained habits
- They understand the basics of putting together a web site
- They are used to source control, commit early and often, and open source
So the new Dotcom 2.0 junior developers have a leg up from the early 2000s. I think more of them will stay in the field. They put some real time and effort into switching or starting a new career an possibly a decent sum of money and they’re more likely to stick it out. And their baseline is a lot better. They’re all feeling really underprepared even in their first paying dev jobs, but they are far better off then the wave that came in the late 90s.
At Axosoft, we open our doors to lots of different people and groups in our community. On any given day, we see new faces touring our office, attending events, and hosting their own groups and meetings in our space. It’s not every day though that we get a group of about 30 kids roaming the halls. That’s why we invited the 8th-grade class at Mission Montessori to come visit us, and we pulled out all the stops!
Upon their arrival, we presented them with dozens of pizzas to fill their hungry bellies. We knew that with full tummies they would be ready to fill their minds with new knowledge. That’s when we took them on a tour of our office and taught them about all the different roles that are necessary to help make a tech company run successfully. They were eager to poke their heads in every room and ask questions. I’d have to say their attention peaked though when they saw the gym, the library/gaming room, and the grand finale… An array of nerf guns for their choosing! I mean, what’s a good office tour without an epic nerf battle?The Periscope recording of the battle
After the adrenaline stopped pumping, we sat down with the kids to give them advice, inspiration and answers to their questions. It was a privilege to be one of the 5 mentors who spoke to these kids. My colleagues who spoke were: 2 senior developers, 1 very recent college grad, and 1 college intern. I was there as a representative for kids interested in working at a tech firm in a role outside of engineering, such as marketing.
I was so impressed with these kids! If you’re not familiar, Mission Montessori schools support the development of children through a curriculum based upon Maria Montessori’s educational philosophy and child development theory, and with an environment designed to help the children:
- Increase intellectual abilities
- Develop personal autonomy
- Practice effective, positive communication skills
- Learn constructive decision-making processes
- Exercise self-discipline and self-control
- Discover the joy of learning that fosters a love of education for life
- Feel joyful and self-confident
- Choose actions which demonstrate respect for self and others
Basically, these kids are smart, ambitious, amazing kids! I was blown away by their enthusiasm for learning and growing. Half the kids wanted to know if they could get internships at Axosoft—remember these are not college kids, they’re 14-year-olds—and they were dead serious!!
It’s important to stay connected to our community and the next generation of aspiring entrepreneurs, developers, and rockstars! These kids are our future, and I’m happy to say I think we’re in good hands
Replacing a 300 page design document with a product backlog filled with thousands of small user stories doesn't provide much benefit. Responding to uncertainty, emergence and change requires a plan which is flexible, communicates the game's vision and doesn't try to document uncertainty away.
Games need a product backlog with a couple of hundred stories at most. Upon hearing this, a question often asked is, "how do we encompass the scope of a large game in just a couple hundred stories?
The Level-of-Detail Metaphor
A useful metaphor to answer this question is the "Level-of-Detail" (LoD) technique, which are often used in video games. This technique chooses different copies of an object to render depending on how far the object is from the camera. In the example on the right, a distant boat will first use the low-polygon model on the bottom. As the boat approaches the camera, it switches to using the higher polygon (or triangle) models above. Ideally, as the boat approaches, you won't notice the models changing (old-popping).
The reason for using LoDs is that graphics engines and hardware have limits on the total number of polygons that can be rendered at 30 to 60 times a second. If you want to have hundreds of boats shown in your game, using LoDs is a common way to render them.
LoDs for User Stories
The same approach is used for the product backlog. The figure below shows some example LoDs for user stories:
Just as LoDs allow games to show a full, complex world on the screen, the LoD approach to product backlogs allows you to encompass the entire vision for the game in one view. Highly detailed documents or backlogs don't allow you to "see the forest through the trees" and, as with a forest, are easier to get lost in.
Level of detail is increased through the practice of splitting stories. You'll find some examples there.
Change is happening fast and furious in the business world. With so much pressure to keep up, it can be hard to take your foot off the gas pedal, even for a few days. Occasionally, though, it’s important to pull over and check the map to make sure you’re still on the right road.
If you’ll excuse the extended metaphor, we’d like to humbly offer RallyON!™ 2015 as a rest stop on your way to business agility.
Register today for the RallyON 2015 Agile conference — and get ready to drive at the new pace of change. Join us as we condense the industry’s most dynamic ideas, strategies, and practices into three days of learning, inspiration, and fun.
When: June 15–17, 2015
Where: JW Marriott Phoenix Desert Ridge Resort & Spa in Phoenix, Arizona
Don’t miss this chance to connect with experts and peers. It’s a rare opportunity to gather fresh insights that will remove your most challenging roadblocks and push your projects forward!
See how organizations like yours are achieving outstanding business results using Lean, Agile, and DevOps practices.
Learn how to create an unstoppable delivery engine, with coordinated teams using the coolest new collaboration tools.
Find out how to amplify the success of your Agile release planning and quarterly business steering to deliver value at scale.
There’s something for everyone, so bring your colleagues! In fact, when you register as a team, you can save up to 30% off the registration cost. See Pricing for more details.Who’s Coming to RallyON?
C-level executives who need business agility to stay ahead of rapid change — whether it’s competition, disruptive technologies, rising consumer demands, or changing regulations
VPs and managers in development and product management who need to improve planning and coordination across teams, so they can connect strategy with execution and ultimately deliver business value
Development team members who are tired of fighting fires and want to gain visibility into work, balance priorities, and respond effectively to the needs of the business
Check out the agenda and search by track (we’ve got seven) to find the sessions that interest you most.
Don’t wait any longer. Register your team today!
Doomsday Machine is lost, if you
*keep* it a *secret*!"
- Missing acceptance criteria?A definition of done applies to all product backlog items, but sometimes you need to define a set of important requirements that are unique for individual stories before they are worked on. These are considered “conditions of satisfaction” for the product owner, or acceptance criteria.
Example: As a player, I want to see a Message-of-the-Day (MOTD) from the developer so that I learn useful things about the game.
Some acceptance criteria for this story might be:
- The MOTD window may only take half the screen.
- It’s only shown the first time someone starts the game during a calendar day.
Types of acceptance criteria:
- Specific functionality known up front (above).
- Special, non-functional requirements (e.g. memory or CPU performance limits), for example “The game should have ten of these effects running with less than 2 milliseconds per frame cost on the target platform”.
- A set of expected behaviors for a subset of features, such as needing persistence in saved games or needing specific tests for online gameplay.
- Known areas that will be incomplete. For example, if you’re implementing a jump feature, but don’t have enough animation support (and have failed to get more), an acceptance criteria might say “some animation transitions will pop”.
- Have a clean pass/fail, testable state.
- Won’t dictate implementation details.
Acceptance criteria can be added to a story any time before, and during, sprint planning. Usually they’ll be added in release planning, grooming and sprint planning with greater detail added as the sprint work approaches. The product owner doesn’t have to be the one to identify them all, but should be present when they are captured. I prefer to have the team there as well asking questions and suggesting acceptance criteria along the way. One useful approach is to have a member of QA or a developer capture any acceptance criteria during discussions of the story, especially in sprint planning.
Acceptance testing will focus the team on the outcome as much as the means of getting there. It allows the business side to build trust with the team and to improve how they communicate their needs. When trust exists, the business is less likely to worry about the sprint and interfere.
Humans typically crawl before we learn to walk, and walk before we learn to run. But sometimes what we call running is really more like a walk, and sometimes when we’re in a real hurry we’ve been known to skip a step.
How we learn to get started with Agile can take a lot of forms. Many people begin with baby steps: piloting a single team or experimenting with daily standups. Others are eager to get into a fast cadence right away and launch whole delivery groups — coordinated teams working on business strategy — all at once.
How we gauge our speed and progress varies, too.
- Some organizations outgrowing stickies on a whiteboard don’t know how to take the next step.
- Some go through the motions of Agile without noticing that their form is pain-inducing, or they’re moving so fast that they don’t have time to look around for competitors.
- Some become so focused on the work in the moment that they lose sight of the finish line altogether.
- Many who are “winning” at Agile forget to retrospect on their success or how to further improve.
Where are you in your Agile journey? Are you eager to take the next step, but don’t know where to start? Do you wonder how you stack up against others?
Now you can find out. Take five minutes to take our Agile Quiz. Get immediate answers, see how you compare to others who do what you do, and get recommendations for what to do next.
If you get a few minutes to talk to your executives about agile… you’ve got to be really crisp about what you are asking for and why.
Far too often people get that few minutes and totally fail to explain why agile is important and why their executives should care.
If you have an opportunity to speak to your leadership team about agile, here are the four things you need to be able to communicate.
1. Show deep understanding of the problems that your executives are trying to solve. Not the problem YOU want to solve, but the problems that THEY are trying to solve.
2. Explain specifically what about the current organization is contributing to these problems and how doing more of the same isn’t likely to lead to a different outcome.
3. Explain the specific changes you’d like to make in the organization. You have to be VERY specific. You can’t tell people to think differently. You have a shot at asking them to behave differently.
4. Make a specific ask for permission… to do a specific action… to prove that your approach to solving the problem could work. Let the executive know specifically what kind of support you need.
You need to be able to do this in about 10 minutes. Here is an example.
1. I deeply understand that we are struggling as an organization to make and meet commitments and get product to market in a timely manner. Our competition is moving faster and taking market share.
2. Our problem is that people are spread too thin across too many initiatives. People are unable to estimate accurately, and when they do, the constant context switching is slowing them down.
3. I’d like to try an experiment where we form a complete cross functional team. Help the team prepare a really clear backlog and we’ll help them produce a working tested increment every couple of weeks.
4. Could I get your support to form a team around our new product. We’d like to use a method called Scrum to manage the team’s work and in three months we’ll be able to get a prototype ready for market.
Obviously, this is an oversimplified example, but I think you get the idea.
Walking into the C-Suite and telling them they don’t get it… that they need to change… that they need to empower people…that they need to let folks self-organize… IMO, doesn’t really cut it.
Just a quick comment as we close… if you don’t understand your executives problems, you don’t have a clear point of view about what is specifically broken, you don’t have a clear plan for how to fix it, and you don’t know how to ask your executive to take action…
Agile delivery practices use metrics as a foundation to quantify the unpredictable nature of understanding what someone has in mind. Stories are a set of words that convey an idea and translate one person’s imagination into an imaginary format called software. Given that we can debate what the definition of “is” is, estimating when some body of work will be done and how far we are in that body of work approaches impossible. However, all Delivery Managers are asked to do exactly that. End of Sprint reports are used to convey to the rest of the business where we are on an imaginary journey and when we will get there.
The Release burn up helps to describe how well the teams are able to complete the work planned for this release. In this team we can see that although the team is tracking to complete the scope originally planned in the release. Scope was added to the plan either by better understanding or changes in definition and the team is not able to complete the growth in scope. Also in this chart we see that the Product Owner is not accepting the scope. This could increase the risk of an on time delivery.
The bug chart helps to give some understanding of the quality of the work. It is important to report all of the defects in the code base. Deciding what to do about the defects is a subject for another blog.
Finally we want to report something about what is happening with the scope. The scope chart below just gives a snapshot in time of how things are going and what areas need focus. The chart shows that the scope is actively being managed but investment decisions may be affected by the discovered scope in one or more features.
The most important part of any report is not the numbers gathered but the narrative that goes along with the numbers. The story of this release so far is that scope has been found or added that the team cannot achieve but they are tracking to make plan. The defects are being well managed and do not appear to cause alarm. Scope is being managed but higher-level decisions need to be made. The View Report feature is not anywhere close to the high level estimate and will impact the team’s ability to take on other work. The team needs help to prioritize whether they should continue with this feature or look for other solutions.
What story is your status report telling?
Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and Its Four Planning Objectives
In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.
In this second blog post, I explain four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.
Agile Planning Framework: 4 planning levels x 4 planning objectives covering 16 practices.
Table 1 presents the recommended Agile Planning Framework, with four agile planning levels represented by its four columns, and four key objectives represented by its four rows. The wording of each objective is the same for all four levels, offering a unified treatment of each objective at all four levels, and also making the objectives easy to understand and manage. However, the implementation of each objective with specific practices depends on the level. For each of the four objectives, there are four practices corresponding to four levels of planning. Altogether there are 4 x 4 = 16 practices covering all four levels of planning and four objectives. These 16 practices are numbered as 1.1 through 1.4, 2.1 through 2.4, 3.1 through 3.4, and 4.4 through 4.4.
Table 1: Customizable Agile Planning Framework with 4 Levels,
4 Objectives and 16 Practices
Objective 1 – Choose and include appropriate method for planning in your Agile Planning Playbook: At each level of planning, Row 1 of Table 1 shows which specific planning method to choose from a set of choices, what specific things to pay attention to, and things to avoid as they cause waste.
Objective 2 – Obtain required inputs for planning and do necessary preparation ahead of the planning sessions: Agile planners must obtain the inputs required for planning and do the necessary planning preparation ahead of each planning session (meeting or workshop). Organizational old habits and inertia might mean multiple reminders and follow-up with at least some people, which some planners may find distasteful (pulling the teeth experience), and may be tempted to skip this diligence. Without required inputs needed for planning and preparatory steps completed, the planning work to be done during a planning session will not be effective. Row 2 of Table 1 lists the input information needed for planning at each level.
Objective 3 – Develop your agile plan: At each level of planning, several outputs must be produced to develop the Agile Plan at that level. Row 3 of Table 1 lists many of these key outputs of the agile plan at each level of planning. Note that the agile plan also needs to specify how workflow against the plan will be monitored.
Objective 4 – Re-plan as required, and improve the agile planning process and agile planning playbook on an on-going basis: An agile plan is not an end-all in itself. As an agile plan gets implemented at each level, lessons are learned through experience, and new inputs are received from the environment (market changes, competitive changes, and business condition changes), the plan itself will need revisions (agile re-planning). The nature and method of re-planning change with the planning level. The need for re-planning must be understood by the highest level of management – an area where agile champions and coaches may need to put some effort to overcome old mindsets.
Lessons learned from developing and executing agile plans at all levels, lessons discussed at reviews and retrospectives at all levels, and inputs received from the environment should become the basis for on-going improvements of the agile planning process and the agile planning playbook at your organization.
Relationship among Agile Planning Framework, Agile Planning Playbook, Agile Plans and their Implementations
Figure 3 shows this relationship along with an explanatory legend. I encourage agile champions to use the Agile Planning Framework presented in this blog series (Blog 1 and 2) to guide the development of your customized Agile Planning Playbook. Customization is done in the way you choose planning levels and planning objectives, and implement 16 practices of Table 1. Agile Planning Playbook is part of the more comprehensive Agile Lifecycle Playbook. Four planning level-specific playbooks are part of the Agile Planning Playbook. Each level of planning provides the context for the next lower level of planning. Implementation at each level provides feedback to the agile plan at that level, and based on the nature of the feedback the agile plan may be revised.
Moreover, implementation at each level provides a second order – what I call “derivative” – feedback to the Agile Planning Playbook; for example, if there is a systemic trend based on several days of daily feedback, it may alter the Agile Daily Planning and Daily Scrum Playbook. As an example, if a team finds it difficult to hold to the scheduled start and end time of their daily Scrum meetings based on daily feedback from several days of work, then the team tries to find the root cause, fixes it, and revises its own Agile Daily Planning and Daily Scrum Playbook.
If a team finds that the same problems have recurred few sprints later even after “fixing” them as a result of an earlier sprint retrospective, the sprint planners and agile champions must explore deeper over the feedback data from a series of sprint retrospectives (hence it is called derivative feedback), address the root cause, and revise their Agile Sprint Planning Playbook. Feedback from few samples in agile implementation is usually enough to drive a change in the agile plan at that level, but it requires sustained or systemic feedback over several samples (derivative feedback) to warrant a change in agile planning playbook at that level. Sometimes, a feedback at one level of agile implementation may be so strong that it could alter the agile plan at a higher level. An agile implementation or a plan or sometimes even a playbook may be altered due to inputs from the environment (market changes, competitive changes, technology issues, business changes). This is not shown in Figure 3 to avoid clutter and to stay focused on the relationship among Framework, Playbooks, Plans and Implementation effort.
Guidelines for customizing the Agile Planning Framework: For a client-specific project of a relatively modest duration (say, six months), you may be able to skip Level 1 planning (Product Vision and Strategy) and start with Level 2: Release Planning, consisting of two release cycles of three months each.
Teams that are new to agile development may start with Level 3: Sprint planning and Level 4: Daily Planning and Daily Scrums. As they gain experience of few sprints under their belt, they may then start doing Level 2: Release planning, and with further experience start with Level 1: Product Vision and Strategy planning.
For entrepreneurial start-ups with high degree of uncertainty about their real customers and their real problems, and about technical feasibility of their solution, staring with a two-year long vision and strategy exercise may not be very productive. A start-up may spend the first several months on Level 3 (Sprints) and Level 4 (Daily) planning and execution to validate their assumptions, demonstrate prototypes to potential customers, and make small changes in the (implicit) strategy or even “pivot” (significantly change) the strategy based on feedback from short sprints. Only when they have a good understanding about real customers and their real problems, and have some confidence in technical feasibility of their solution, they may advance to Level 2 (Release) and finally to Level 1 (Product Vision and Strategy) planning.
For a very large organization with many portfolios, programs and projects, you may have five levels of planning: Portfolio vision and strategy, Product vision and strategy, Release planning, Sprint planning, and Daily Planning and Daily Scrums. Alternatively, you may choose to have multiple Agile Planning Books targeted for different lines of businesses or product lines.
For well-jelled, highly experienced and stable teams that have demonstrated a stable velocity pattern (velocity changes within a narrow range across successive sprints), Planning Level 4 can be substantially simplified. Such teams should still conduct Daily Scrum meetings and may break stories into SMART tasks, but may track the effort for an entire story, and not at the task level.
You may add one or a small number of new objectives (beyond four objectives in Table 1) to your Agile Planning Framework, if required for your specific situation. Ability to add new planning levels and new objectives makes the Agile Planning Framework extensible. If you decide to add new levels or new objectives, I will be very interested in knowing the reasons (you may send me an email at Satish.Thatte@VersionOne.com). If you delete or modify or relax any of these four objectives, your agile plan will be incomplete or inadequate or of poorer quality compared to a plan developed by rigorously and diligently following all four objectives.
From Agile Planning Framework to your customizable agile planning playbook: Agile champions owning the agile planning playbook have many important responsibilities:
- Take the Agile Planning Framework from this blog series and customize it to create your agile planning playbook, instead of developing the playbook from scratch. This will save you substantial effort and result into a better and higher-quality playbook.
- Choose your own method for implementing each of 16 practices of Table 1. Furthermore, you should explore how to integrate your agile planning playbook with your Agile Lifecycle Management platform (see below) as that will make its actual use by agile champions, agile planners and agile team members much more likely and natural.
- After getting the buy-in and commitment for agile planning from your senior executives, educate agile planners and stakeholders in your organization on the agile planning playbook to be used in your company, and also get their inputs in developing your agile planning playbook.
- Make sure that your agile planning playbook is followed by agile planners at all four levels of agile planning, and even more importantly agile team members do their work driven by those plans.
- Improve the agile planning process and the playbook on an on-going basis.
The resulting agile planning playbook can be a brief document or a set of wiki pages. However, this solution will be disconnected from and will be poorly integrated with your ALM platform, and may not get used much as it is an “out-of-band” solution; and for that reason, it’s not my favorite. I strongly recommend that you implement and operationalize your agile planning playbook as an “in-band” solution that is well-integrated with your ALM platform.
If you are using or planning to use VersionOne as your ALM platform, I encourage you to implement your agile planning playbook using VersionOne Communities, Templates, Reporting and Customization capabilities, pilot your playbook with few agile projects, and then roll it out at a larger scale. If you have questions on how to implement and operationalize your customized agile planning playbook or to implement a more comprehensive agile lifecycle playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.
Though last but not the least, the agile planning playbook is necessary but not sufficient for agile success. Excellence in agile project execution is also essential, in addition to be good at agile planning. However excellence in execution will not be effective in delivering business results without proper agile planning.
The next five blogs of this blog series: In the next blog (Blog 2 of this series), I will explain four objectives at each planning level of the Agile Planning Framework. In the following four blogs (Blog 3 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.
- Blog 3: Plan and Succeed Strategically using Your Agile Product Vision and Strategy Planning Playbook
- Blog 4: Plan and Succeed in each Release using Your Agile Release Planning Playbook
- Blog 5: Plan and Succeed in each Sprint using Your Agile Sprint Planning Playbook
- Blog 6: Plan and Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook
In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.
If you have questions on how to implement and operationalize your customized Agile Planning Playbook or to implement a more comprehensive Agile Lifecycle Playbook covering the entire agile project lifecycle, please let us know at Services@VersionOne.com.
Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) or on Twitter (@smthatte).
Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne. He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level. He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.
His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute. Learn more about Satish and his blogs at LinkedIn and blogs.
“Hi, I had a question. Our Scrum Master is acting like a manager, running all the meetings and assigning work. This is what they did before Scrum. I thought Scrum meant the team did this stuff?” - A developer
The values of Scrum apply here.
Scrum! Scrum! Scrum! Scrum!
The sprint is the team’s commitment to a goal. True commitment to the game and continuous improvement requires a level of ownership, otherwise it’s an environment of compliance and people don’t engage as well with that.
The barrier to allowing ownership is fear. I often hear the micro-managing Scrum Master’s fear of what will happen if the team doesn’t follow their leadership. "They might fail!", they cry. There is often an underlying suspicion that others on the team are not competent because they'll make mistakes. The news is that competence doesn't mean you don't make mistakes!
Allowing teams to make mistakes and safely fail from time-to-time requires trust and courage. Trust requires respect. A lack of trust and respect is a cultural root of evil. When I see locked supply cabinets, dictated core hours or time-sheets, web filters, people referred to as “resources” etc. I know that the true adoption of Scrum will be a bit harder.
How can this be done?
Courage is requiredShifting from a mindset of individual compliance to team commitment requires courage all around. The Scrum Master and the team must summon the courage to take chances and fail every once in awhile. Emboldening the team to find this courage is more challenging than micromanaging via a task spreadsheet, but it’s also more fulfilling. It doesn’t happen overnight, but trust and respect can be grown.
Scrum Masters can start with some simple things:
- Silence yourself! Stop doing all the talking. Learn to allow awkward silences. The team will fill the silence with their own ideas and solutions.
- Ask questions, even when you know the answer. Teach them to catch fish rather than giving them fish to eat.
- Be courageous. Demonstrate respect and protect the team.
For example: if an artist is having problems getting code to work with a model, the entire sprint goal is threatened, but the team's focus on their shared goal should guide them to solve this problem on their own. There is no need to blame the artist for not solving their own problem. There is no need for someone wearing a manager’s hat to assign an engineer to fix the problem.
Does this mean managers/producers should be fired?
Don't expect leadership to
be overthrown, but leveragedAn underlying fear from managers or producers jumping into the Scrum Master role is that they should continue doing what they've been good at in the past or they'll be let go.
In the ten years that I have been training teams to use Scrum, I haven’t seen this happen. I’m not saying it never will, but most stories I hear reflect my own as a manager in a studio that adopted Scrum.
I found that as teams became more self-organizing, there was a growing part of my time that needed to be filled with other things. Eventually, about half my day was freed up by not micro-managing. This wasn’t bad because the work that teams took from me was never the work I enjoyed doing. So, I joined a team as their product owner and ended up enjoying the work far more as I was closer to the game and the people making it.
This might not be the path for every manager. Agile should lead a studio to ask what practices and roles are benefitting their games and the people making them and what parts are not. Again, this can threaten the status quo, which is why a lot of larger, established studios have a harder time adopting agile.
"Now I can make cool movies about
monkeys taking over the world!"The bottom line is that these values have to win out for you to have full success with agile.