10 Agile Books You Should Read This Summer

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.

Sutherland bookScrum: The Art of Doing Twice the Work in Half the Time
By Jeff Sutherland

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.

*Book description from Amazon

Cobb bookThe Project Manager’s Guide to Mastering Agile:
Principles and Practices for an Adaptive Approach

By Charles G. Cobb

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.

*Book description from Amazon

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

AgileChangeMgtAgile 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.

*Book description from Amazon

AgileMgt(1)Agile Management for Software Engineering:
Applying the Theory of Constraints for Business Results

By David J. Anderson

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.

*Book description from Amazon

AgileMgtLeadershipAgile Management
By Ángel Medinilla

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.

*Book description from Amazon

AgileCoachingAgile Coaching Paperback
By Rachel Davies and Liz Sedley

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.

*Book description from Amazon

AgileEstimatingAgile Estimating and Planning Kindle Edition
By Mike Cohn

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

*Book description from Amazon

AgileExperience_Agile Experience Design: A Digital Designer’s Guide to Agile, Lean, and Continuous (Voices That Matter)
By Lindsay Ratcliffe

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

AgileProjMgtAgile 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!

*Book description from Amazon

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?

Posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Leadership, Agile Management, Agile Methodologies, Agile Project Management, Agile Software, Scrum Development, Scrum Methodology, Uncategorized | Leave a comment

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

Table1A

Table1BObjective 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.

Fig3_APF_APP

Fig4_Legendfor_Fig3Figure 3: Relationship among Agile Planning Framework, Agile Planning Playbooks, Agile Plans and Implementation

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).


versionone-coaches-satish-thatteAbout the Author
Dr. Satish Thatte
SPC, CSM, CSPO, CSP

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.

Posted in Agile Adoption, Agile Coaching, Agile Leadership, Agile Management, Agile Methodologies, Agile Portfolio Management, agile program management, Agile Project Management, Enterprise Agile, scaled agile | Leave a comment

Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels

Many people know that agile planning is different from big up-front detailed planning done in traditional or waterfall projects.  However, there are many misconceptions or only partial understandings of agile planning.

In this first blog post in a series of six, I will begin to explain the details of agile planning: what and why, and multi-level planning and its benefits.

What is Agile Planning?

Some people equate agile planning with minimal planning or just-in-time planning or “fluid” or “adaptive” planning or planning to be done by the whole team not managers – all these characterizations cover only some aspects of agile planning.  Agile planning is more involved, more disciplined, and rigorous than what some people think.

If done right, agile planning requires modest time and effort. This planning effort should not be viewed as an overhead, or a chore to be done by “agile project managers”. Planning is part of the overall work. If you don’t plan or plan poorly, no amount of execution effort would adequately compensate for poor agile planning. “Winging” an agile plan is expensive and doesn’t work well. As Benjamin Franklin said, “If you fail to plan, you are planning to fail!

The Agile Planning Framework is based on multiple levels of planning – typically four levels – as illustrated in Figure 1.

  • Level 1: Product vision and strategy planning – this is the top level of planning
  • Level 2: Release planning
  • Level 3: Sprint planning
  • Level 4: Daily planning and daily Scrums – this is the bottom level of planning

Figure 1 also illustrates the key goals at each of four planning levels.  Each level of planning is elaborated and supported by the next lower level of planning at smaller planning units, but with greater details (elaboration) and on a shorter planning time horizon, as will be explained soon.  Figure 1 is based on a popular poster from VersionOne that you may download for your use.

Fig1_Planning_Levels

Figure 1: Four Levels of Agile Planning

The Three Agile Planning Roles

Note that these are roles, and not necessarily three distinct sets of people.  Many planners also implement the plan, and many implementers are involved in planning.  In many organizations, the same person may play one or more of these roles. A sprint planner could be a team member doing his/her Daily planning and may also be a release planner. A release planner could also play the role of an agile champion. A software architect could be a team member, sprint planner, release planner, product vision and strategy planner, and agile champion. Each team member is a daily planner and is expected to work and deliver on that daily plan.

1. Agile champions: Agile champions are responsible for implementing, maintaining and improving an organization’s customized agile planning playbook by briefly and effectively documenting the agile planning process at each level as well as evangelizing and teaching the planning process to agile planners. The champions also revise and improve the agile planning playbook based on the feedback from agile planners, agile team members, as well as changing market conditions, competitive response, business conditions, technology changes, etc.

These agile champions are the owners of your agile planning playbook. They may be senior executives or senior managers responsible for your organization’s agile transformation. They could also come from your enterprise’s agile Project Management Office (PMO) or they may be a group of enthusiastic and committed ScrumMasters if the agile initiative is started at the team level.

2. Agile planners: Agile planners are responsible for following the agile planning playbook to conduct planning and do re-planning as is necessary. An agile plan needs to be revised and adjusted at an appropriate frequency (based on the agile planning level) based on the feedback from agile team members, stakeholders, and also from the environment, as explained below. Agile planners work with the appropriate stakeholders to seek their input, guidance and expertise in the planning process.

3. Agile team members: Agile team members are responsible for day-to-day work of developing, delivering, deploying, operationalizing and supporting agile project deliverables after each sprint and release cycle. This day-to-day work is driven by agile plans developed by the planners at each level. These self-organized team members should have cross-functional expertise in areas of analysis, software design, user experience design, code development, testing, technical writing, data center deployment and operations, etc. Note that agile team members are not only daily planners, but also sprint planners; some of them may participate in release planning, and some may be called upon to help in product vision and strategy planning.

The Four Guidelines for Agile Planning

1. Plan and elaborate progressively at each planning level: Planning done at each level is a pre-requisite for the next lower level of planning. It serves as the context and guides planning at the next lower level.  Product vision and strategy planning (Level 1) should proceed in the context of completed planning at the business vision and strategy done by senior C-level executives responsible for overall business; as this planning is related to the overall enterprise business, it is outside in the scope of this blog series.   Without a reasonable business vision and strategy in place, planning product vision and strategy is difficult and ineffective.  Release planning (Level 2) should proceed in the context of completed planning at the Product vision and strategy (Level 1).   Without a reasonable product vision and strategy in place, Release planning is very difficult.   Sprint planning (Level 3) should proceed in the context of completed release planning (Level 2).  Without a reasonable Release plan in place, Sprint planning could be difficult or at best tactical.  Daily planning and daily Scrums (Level 4) should proceed in the context of completed sprint planning (Level 3).  Without a reasonable sprint plan in place, daily planning is not very effective.  It is not advisable to plan at a level and then skip one or two levels to jump to a lower level; for example, starting at planning level 1, skipping Level 2, and jumping to Level 3 should be avoided.

2. Choose proper planning horizon, and granularity of planning and workflow monitoring at each level of planning: Planning time horizon should start with a typical 1 to 3 year range at Level 1 (product vision and strategy) and should shrink to a single workday at Level 4 (daily planning and daily Scrum). As planning time horizon shrinks, the granularity for planning and workflow monitoring should also shrink from “very large” (at Level 1) to “very small” (at Level 4).

Level 1 – Product vision and strategy planning: Large to very large planning and workflow monitoring units, such as product goals and initiatives, strategic themes. These units are typically modeled as initiative epics and may take several months or release cycles to complete.

Level 2 – Release planning: Moderate planning and workflow monitoring units, typically modelled as feature epics that can be completed in a single release cycle consisting of multiple sprints.

Level 3 – Sprint planning: Small planning and workflow monitoring units, such as user stories and other work items (defects, spikes, regression test cases, etc.) that can be completed in a single sprint.

Level 4: Daily planning and daily Scrum: Very small planning and workflow monitoring units which are SMART tasks that implement a story or a work item. A SMART task is completed typically in four hours or less in a single workday.  Acronym SMART stands for: S: Small, M: Measurable, A: Achievable, R: Realistic and T: Time-bound

With longer time horizon, it makes sense to plan and monitor workflow at larger granularity of work. When planning horizon is long-term (Level 1 planning), working on small or medium-grain planning units (stories and epics) makes little sense as those small work items usually are not even known during Level 1 planning, and it would be a wasteful practice as many small work items will almost certainly change over time even if we spend effort to identify and model them during Level 1 planning.

3. Identify proper agile planners and stakeholders that must work together with commitment to required planning preparation and allocation of required planning time: Agile champions in your organization should identify the right planners and appropriate stakeholders at each level of planning, and those agile planners must work with the right stakeholders effectively. Agile planners must be well prepared and committed to attend all planning meetings and workshops with their quality time and focus without interruptions.  This often requires a cultural change in many organizations, and may need executive support and sustenance.  This also requires training of agile planners and stakeholders, and guidance by qualified coaches to conduct agile planning workshops at each level of planning.

Product vision and strategy planners and their planning time: Executives work with Product manager and other appropriate stakeholders. Three to nine days of planning effort is typically required depending on the product size, duration and complexity for a one to three year product horizon (240 workdays per year). A product vision and strategy plan should be revised or fine-tuned at the end of each release cycle.  If you consider additional one to three days of effort to maintain and revise the Product Vision and Strategy Plan, it still amounts to only 2% of total time for planners at this planning level.

Release planners and their planning time: Release manager, product owner, ScrumMaster and team leads work with managers and representatives of other related release teams (for large projects). Two to four days of planning effort is typically required for a three to six months release cycle (22 workdays per month).  A release plan should be revised at the end of each sprint cycle.   If you consider additional 0.5 to 1 day of effort to maintain and revise the release plan, it still amounts to a very modest 4% of total time for planners at this level of planning.

Sprint planners and their planning time: The whole team (all its members) does planning and works with managers and representatives of other related teams (for large project). Four to eight hours of planning effort is typically required for a two- to four-week sprint (five workdays per week). This amounts to a modest 5% of total time for planners at this level of planning.

Daily planners and time for planning and attending Daily Scrums: Each team member plans his/her individual daily work, typically requiring 10 minutes of daily personal work planning effort.  This planning must be completed prior to each daily Scrum meeting which takes another “2n+5” minutes, where “n” is the number of team members in a team (see my blog series on how to make Daily Scrums Effective and Efficient); it takes two minutes for each team member to present his/her daily work plan and to report against the plan of the previous workday (tasks done or not done), and another five minutes for the team to review key metric such as the burn-down and burn-up reports.  Thus it takes 15 to 23 minutes per day (depending on the size of the team ranging from 5 to 9 cross-functional, self-organized team members) to conduct the daily Scrum meetings.  The total time to prepare the daily plan and attend the daily Scrum is 25 to 33 minutes.  This amounts to a modest 5% to 7% of total time for each team member.

In future blogs of this blog series, I will present the details of the recommended schedule and cadence for the planning sessions at all four planning levels.

4. Define workflows at each level of planning and execution:

Each higher level of planning sets the context and drives the work at lower levels of planning as illustrated in Figure 2.  Agile planners must define the workflow at each level of planning.  As shown in Figure 2, at Product Vision and Strategy planning level, work items are modeled as Initiative epics and they flow in sequential stages: Approve and Fund, Implement, Deployed, and Measure Return on Investment (ROI).   As an Initiative epic reaches Implement status, it signals that work can be initiated at the next lower level, i.e., Release planning level.  An Initiative epic gives rise to many Feature epics at the Release planning level; when a feature epic is broken down into stories and reaches the Build status, it signals that work can be initiated at the Sprint planning level.  When a user story reaches Development status in a sprint, its SMART tasks are pulled by individual team members to work on and their workflow is monitored on the Taskboard as part of Daily workflow.  When all tasks for a story are completed, the story is Accepted by Product Owner (assuming it passes all its acceptances tests), and gets Deployed.  When all stories for a Feature epic are Deployed, that Feature epic moves to Deployed status on Feature Epicboard.  When all Feature epics of an Initiative epic are Deployed, the Initiative epic moves to Deployed status on the Initiative Epicboard.

Agile planners need to define policies for managing workflows at each level (rules for status transitions); and board-level policies, such as Work-in-Process (WIP) limits, cycle time thresholds, etc.   There is plenty of opportunities to customize the workflows, status columns, and policies at each level of planning.   I will explain the workflow at all four planning level in four future blogs of this blog series.Fig2V4_Workflows

Figure 2: Customizable Workflows at Each Agile Planning Level

Agile Planning Playbook

As my colleague Mike McLaughlin explained in his agile playbook blog, an agile playbook is a helpful guide that briefly documents your agile process. I believe an agile lifecycle playbook should cover the entire value stream from product vision, strategy, analysis, design, development, testing, delivery, deployment, operations, support, and customer value realization. These are not sequential phases of work; often agile team members “swarm” to do many tasks concurrently and in close harmony, such as analysis, design, development, testing; and even deployment and operations as the DevOps movement proposes.

An agile lifecycle playbook helps ensure consistency among projects and teams, improves their productivity and quality of work and reduces mistakes and errors. VersionOne’s 9th Annual State of Agile™ survey has indicated that the consistent process and practices is the top tip for success in scaling agile.    You can and should start using your agile lifecycle playbook even with single teams and smaller projects to ensure consistency across successive sprints, and improve your playbook with on-going experience.

An agile planning playbook focuses on agile planning aspects of the agile lifecycle, and is a part of the overall agile lifecycle playbook for your organization. Your agile planning playbook facilitates agile planning in a standard and consistent way across the whole enterprise or at least across a set of common projects or teams. There is no “one size fits all” agile planning playbook that suits all organizations.

Consider these very different types of organizations.

  • A relatively small company working on its next product over multiple release cycles with four agile teams consisting of a total of 35 members
  • A large bank with portfolios of many projects consisting of 1,200 project members and developing software for in-house use
  • An organization developing and operating a large e-Commerce service through Internet cloud
  • A Department of Defense contractor developing a mission-critical system (hardware and embedded software) spanning five years of development cycle

Each organization, product, program or project, as well as teams and people and their practices, history and cultures are unique.  Therefore each organization or a division or a line of business will need a customized agile lifecycle playbook and agile planning playbook to serve its unique needs and business goals. However, agile planning needs of diverse organizations share a common core based on agile principles, values, and agile framework.

The Agile Planning Framework is based on a common core of agile planning principles and practices.  The framework is common for all organizations interested in agile development. Your organization can develop one or more agile planning playbooks from the common framework by customizing and implementing it in ways that best serves your needs.

Most of the material in this blog series is written with a focus on the lifecycle of software products or services or embedded software products that are intended for multiple customers in their chosen market segment.  With appropriate modifications, you can use this framework for a number of different situations, such as:

  • Single client-specific custom software project
  • An entrepreneurial start-up company with a lot of uncertainty
  • Scaled agile environments where there may be many portfolios of programs and projects

I will explain how you can modify the Agile Planning Framework to suit these different situations throughout this blog series.

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.

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).


versionone-coaches-satish-thatteAbout the Author

Dr. Satish Thatte
SPC, CSM, CSPO, CSP

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.

Posted in Agile Benefits, Agile Coaching, Agile Leadership, Agile Methodologies, Agile Portfolio Management, agile program management, Agile Project Management | Leave a comment

10 Agile Quotes From The World’s Most Brilliant Minds

Truly embracing agile can be a very hard task; agile practices are mostly learned and experienced, not something that you can easily glean from a book or article. But if you’re in search for valuable agile quotes to inspire you and your teams, here are 10 from the world’s most brilliant minds.

Brilliant Agile Quotes

Einstein

 

 

 

 

 

 

 

 

1) “Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”
– Albert Einstein

As agile organizations, teams and team members, we must constantly question what could be better in order to continually improve.

Lombardi

 

 

 

 

 

 

 

 

2) “Perfection is not attainable, but if we chase perfection we can catch excellence.”
-Vince Lombardi

Perfection is a fallacy that leads to over planning, procrastination and failure to ship; agile is about focusing on delivering the best thing possible in a set time period.

Suess

 

 

 

 

 

 

 

3) “Unless someone like you cares a whole awful lot, nothing is going to get better.
It’s not.”
– Dr. Seuss

Agile practices focus on giving teams and individuals ownership of their work and accountability to the team and organization, so that you can care to make things better.

Ali

 

 

 

 

 

 

 

 

4) “Service to others is the rent you pay for your room here on earth.”
– Muhammad Ali

Service leadership and selflessness are foundation principles of agile; these are the prices to be paid to be part of an agile team.

Lucas

 

 

 

 

 

 

 

 

5) “You simply have to put one foot in front of the other and keep going. Put blinders on and plow right ahead.”
– George Lucas

Agile is about doing as opposed to being paralyzed by over-planning; in agile you get the minimal necessary requirements and start working.

Confuscus

 

 

 

 

 

 

 

 

6) “It does not matter how slowly you go as long as you do not stop.”
– Confucius

A core principle of agile is working at a constant pace, which in turn enables you to deliver at a constant pace, as opposed to working sporadically and delivering nothing.

Angelou

 

 

 

 

 

 

 

 

7) “We may encounter many defeats but we must not be defeated.”
– Maya Angelou

You will inevitably run into challenges along your agile journey, the key is to learn from these challenges and overcome them through standups and retrospectives.

Hawking

 

 

 

 

 

 

 

 

8) “Intelligence is the ability to adapt to change.”
– Stephen Hawking

Agile is all about adapting to change; it was built on the foundational principle that business drivers will change and the development teams must be ready to adapt.

Edison

 

 

 

 

 

 

 

 

9) “Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.”
– Thomas A. Edison

In agile as in life there will be hiccups, but the iterative nature of agile makes it easy to do a retrospective and learn from our mistakes then move on to the next sprint and do better.

Disney

 

 

 

 

 

 

 

 

10)”If you can dream it, you can do it.”
– Walt Disney

We should never forget that agile was formed to find a way to develop software better and to more easily conquer our dreams.

What is your favorite quote as it relates to agile?

Posted in Agile Adoption, Agile Benefits, Agile Project Management, Agile Teams, Continuous Delivery, continuous improvement, Uncategorized | Leave a comment

Why Agile Won’t Make You More Productive

PrintAccording to the 9th annual State of Agile™ survey, more organizations are adopting agile in order to improve productivity:

“Consistent with last year, most respondents adopted agile practices to accelerate product delivery (59%) or enhance their ability to manage changing priorities (56%). However, in 2014, productivity (53%) has moved into the top 3, outranking last year’s #3 response – improved IT and business alignment.”

This made me wonder why there is a perception that if companies transition to agile, teams will be more productive. I put my waterfall hat on and read the twelve principles that support the Agile Manifesto from a traditional stance. I could see where delivering working software frequently and at a sustainable pace speaks to teams being more productive in agile.

For example, a project that is managed with a traditional waterfall process has big upfront design and is transitioned over to a team that knows they have six to nine months to produce the software. At the beginning of project, the teams are more relaxed and moving slower. The intensity level and sense of urgency is a lot lower. Then as time goes on – three months, six months – the teams and management start to miscommunicate and stop being as diligent about status meetings. Near the end of the project suddenly the pressure and a bit of panic set in. Teams and management are panicking because now they have to scramble to get the software finished. Maybe this is what creates the perception with waterfall that your teams are not constantly producing software; there’s an ebb and flow.

Waterfall projects start out with very low intensity. By the end of the project the intensity is extremely high and teams are burned out because they’re working crazy hours. The teams are producing low-quality code because they have to rush and the code isn’t being tested. The low quality work damages the team’s pride, which decreases morale and can lead to turnover.

The benefit of going to agile is that the team maintains a constant level of intensity and consistent working hours, which in turn empowers the team to produce beautifully working software at a constant pace.

So when people are saying “productivity,” what I think they really mean is “intensity.” If we’re maintaining a constant level of working hours, a constant level of quality and a constant level of delivery, teams are happier, they’re proud of their work and they enjoy going to work. This is super important because keeping good developers is really difficult. If good developers aren’t happy they can easily leave and go somewhere else. That’s why 26% of respondents to the 9th annual State of Agile survey said improving team morale was the reason they adopted agile.

That’s my take on why there is a perception that agile is more productive than waterfall. When I saw the 9th annual State of Agile survey, I was curious about why people felt that if they moved to agile their teams were going to be more productive.

Why do you think there’s a perception that if companies go agile, teams will be more productive?

State of Agile is a trademark of VersionOne Inc.

versionone-coaches-susan-evansAbout the Author
Susan Evans
SAFe Agilist, CSP, CSM, PMP, PMI-ACP

Susan has more than eight years of agile project management experience in software development. Prior to joining the company, she was an internal coach who optimized the usage of the VersionOne platform to help many non-collocated teams thrive in their agile processes. Susan focuses on enhancing team relationships, communication skills, conflict resolution, and processes to help create happy teams that deliver high quality.

 

Posted in Agile Adoption, Agile Benefits, Agile Management, Agile Project Management, Agile Teams, Uncategorized | 5 Comments

Improving Agile Portfolio Management Coordination

shutterstock_111588257

 

 

 

 

 

 

 

 

Simply producing status reports in an enterprise with hundreds of software development teams isn’t enough to ensure that your products will be delivered on time. You have to ensure that the plans, dependencies, progress and schedules of those teams are all coordinated.

So, how can you coordinate the software delivery across multiple large-scaled systems across hundreds of enterprise software development teams?

Enterprise Software Development Coordination

Whether you’re coordinating several teams or hundreds of enterprise software development teams, you need clear visibility of plans, dependencies, progress and schedules across your portfolios, programs and projects. While it’s simple and easy to look at just a single feature and understand the dependencies and progress of various teams, it’s much more complex when you’re working with a portfolio or program that includes many features that can raise questions about what should be prioritized first in the various backlogs. As a portfolio or program manager you have to do some juggling, planning and coordination to make sure that the portfolio and program level features are moving and progressing as they should, and that all of the work that is needed to support and deliver your programs is really happening down at the team levels.

Let’s take a relatively simple example of an organization with multiple products in a suite. Each product has a team dedicated to its development. Some features are product specific and left to the product owners to drive per product. Some organizational level initiatives, however, may cross all of the products to drive forward company-wide strategies. If this is, say a U.S. company with a corporate initiative to expand into foreign markets, there can be many product and organization ramifications. Sales and services capabilities must exist in Europe. Products must support Value Added Taxes and multiple currencies, perhaps even multiple languages. Support teams must be able to handle extended hours and languages. Clearly, there is a great deal of coordination required to deliver on such an initiative and the better a businesses can handle such a challenge, the better its chances of thriving in a global marketplace.

Coordinating Plans

Each product that an initiative touches must be delivered in a coordinated fashion to provide the most business value possible. So you must plan out an initiative that spans multiple systems as a whole unit. That starts with prioritizing the work at the initiative level, then prioritizing and scheduling the various features that need to be delivered across teams in order to realize the business value of that initiative. By planning first at the initiative and then feature level, we can minimize Work–In-Progress (WIP) and get more value delivered quicker.

From a coordination standpoint it’s important to be able to see what the teams are planning as they’re doing the work, and to see whether or not they look like they’re on track to be able to deliver at the level where the business value can actually be realized. If we have three systems that are all working together to support a given initiative and only two of the systems deliver their parts within the scheduled release, we’ve wasted the effort of the two teams that did deliver. Take for example a feature that essentially is a transaction that goes from system A to system B to system C. If systems A and C plan their features for Release 1, but B plans its feature for Release 2, we don’t get to realize the value of that initiative until Release 2. A and C would be better off planning capabilities for Release 1 that could be used by the customer when Release 1 is delivered.

Coordinating Dependencies

An important consideration in coordinating your software teams is to understand which stories and teams are dependent on each other to produce a working release of software. It’s important to be able to quickly understand where those specific dependencies exist and how they fit into your greater program. On related features across products, not every story will have a dependency. It is important to understand, identify and track those stories and features that have dependencies across teams. For example, system A may require an update to a central security component that is managed by a specialized team. Both system A’s team and the security component team need to understand that linkage, coordinate the timing and track the plans of the other team as they evolve.

Building a dependency diagram at the epic level of your program will help you understand what features and initiatives are dependent on each other. Mapping your program’s dependencies provides visibility into the teams that require extra coordination and communication to remain in lock-step so they can deliver your product on time.

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

 

Coordinating Progress

In addition to tracking progress at the team level, it is important to track at the feature and initiative level as well. Business value resides at these higher levels, so it is imperative that organizations work to track progress and throughput at that level to keep the focus where the business value lives. This is best accomplished by having Kanban boards to view and understand the progress at the various levels of your program. Depending on the size of your organization you may have multiple levels of planning and monitoring. Large enterprises typically have an overarching portfolio level, followed by a program level and finally a team or project level. At the portfolio and program level there are high-level initiatives that are being developed which will typically be decomposed into multiple features that may spread across several different systems. Those features then get broken down into stories the teams are going to deliver. To effectively monitor these multiple levels, you’ll want the flexibility of tracking each level independently and understanding the context of features and how they relate to the higher level initiatives being driven.
Agile Portfolio Management Kanban Board Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

Agile Portfolio Management Dependency Diagram Screenshot from VersionOne

 

 

 

 

 

 

 

 

At the team or project level, create storyboards and make sure the individual stories are part of epics that represent a program or feature on your program board. Storyboards enable you to see all the low level details of stories and how those details roll up into a feature. This allows you to drill down into the next level of detail needed. By mapping your programs with epic boards and storyboards you have the visibility to see your programs’ high level flow, medium level flow and low level flow. The dependency diagram lets you easily understand which initiatives, programs, epics, projects and stories are dependent on one another so that you can coordinate their progress.

Coordinating Time

Easily viewing progress and dependencies across an entire portfolio helps overcome many of the challenges associated with scaling agile across large enterprises, but it will not cure all ills. In order to fully coordinate your portfolio and programs you must be able to view progress and dependencies in relation to your delivery schedule. This is where it is good to have a timeline view. Your timeline should be connected to your dependency diagrams, epic boards and storyboards, enabling you to drill down into initiatives, programs, epics, projects and stories.

Agile Portfolio Management Timeline from VersionOne

Agile Portfolio Management Timeline from VersionOne

 

 

 

 

 

 

 

 

With a timeline view you can take an initiative and drill down into the features. This allows executives and PMOs to have visibility into when all the features are scheduled within a single view. Within a single view you can get an understanding of whether or not the delivery dates for programs, features and stories are coordinated across various levels of the portfolio and programs. For example if you have an initiative that you’re thinking you’re going to deliver in June, but then when you drill down into it you see that you have features for that initiative spreading out into July and August, that could be a problem. Being able to see views like that enables you to understand what may be at risk and what changes may need to be made.

Coordinating the Portfolio

By tracking progress, dependencies and release dates you can easily coordinate the progress of your portfolio from the very highest level, that of the initiative, to the very lowest level, that of the stories. Coordinating the portfolio will help increase the throughput of business value. These three views enable you to drill down and be able to see the progress of all your features from a delivery standpoint. Are they completed? Are they in progress right now? Do we have some that we haven’t even started yet? What is the status? What are the plans for this? Epic boards, dependency diagrams and timelines provide you with visibility into the progress of all of your initiatives. They allow you to see all of the features that a given organization might be working on. Or, they can show you all of the features that roll up into a certain initiative, providing that next level of detail to see what’s where from a delivery standpoint.

Whether you are an executive, line of business person, or a program manager, you can take a look at whether your teams are coordinated up and down the portfolio, program and team delivery levels. Being able to track across the various levels is extremely important. That’s the ideal way to manage the course of delivery. We’re tracking, monitoring, watching and having conversations between those various levels of delivery.

Conclusion

Coordinating software delivery across an enterprise of software development teams isn’t easy. However, if you organize, plan and track your portfolio as laid out above, you will not only deliver software on-time but you’ll help your organization maximize the throughput of business value.

So, how are you coordinating software delivery? VersionOne can help. 

Posted in agile dashboard, agile portfolio, Agile Portfolio Management, agile program, agile program management, scaled agile, Scaling Agile, Uncategorized | Leave a comment

What DONE Looks Like in DevOps

shutterstock_107535005Have you ever wondered about the meaning of DONE in DevOps? If you’re including DevOps in the definition of DONE, what are the agile changes that need to occur? Tweet This.

Fortunately, after working with many organizations exploring these questions, I’ve figured out that the answer isn’t that difficult.

So, what’s the meaning of DONE in a DevOps world?

Definition of Done in a DevOps World

DevOps creates the need for a lot of changes in the development process, not just from the technical aspect of continuous delivery, etc., but also with regards to agile. One of the aspects of agile that’s most interesting is the definition of DONE in a DevOps environment.

This isn’t a new problem by any means; people have been arguing about what the definition of DONE should be since Scrum became popular, and maybe even prior. As development teams begin to infuse DevOps practices, they need to rethink the definition of DONE. In the DevOps world, DONE doesn’t just mean it is coded and tested; it means it will work in production.

A few years back, at one of VersionOne’s AgilePalooza events, a tester asked a question that saddened me. She asked, “So what do you do when the story is done, but it hasn’t been tested?” I think a tear rolled down the cheek of each of the panelists as we had to explain, “it’s not done, if it hasn’t been tested.”

Fast forward a few years, and now we are in a world where most people recognize if code hasn’t been tested or the story is not done and stories are still missing the hooks for monitoring tools. There may be no way of saying, “It is not done until we know that it can be deployed safely and we can monitor its health while it is in deployment.”

In advocating change, I am suggesting the addition of DevOps requirements to your definition of DONE. I’m asking for you to agree that no story is done until the code has been written. And if you aren’t pair programming, then the peer review has happened, the tests are all passing, and the hooks for monitoring, performance evaluation and health checks are in as well. This is vital if you want to be successful with DevOps.

DevOps is all about moving quickly and deploying continuously. If you’re going to deploy continuously, you need to know that what you’re putting out is ready to go out. That means you have to be prepared for when the code meets the real world. You need to know right away if something bad happens when the code is deployed. You can’t wait until somebody calls and asks, “Why can’t I get onto your website anymore?” That is not good enough. If you deploy something, you have to find out before the customer does if something is not working right.

You have to make a few additions to stories to incorporate DevOps into the definition of DONE. The first step is adding the requirements to enable you to understand how the code is doing after deployment. Second, when you are planning a story, you’re going to need to estimate based on what it means to have the code in a state that will be successful post-deployment. Third, every single member of the team is a developer, and every single member of the team is a tester. Every single member of the team is now on the operations staff as well. That is where true success will happen in the DevOps world.

Conclusion

If you’re not fusing DevOps into your agile stories, you should start doing so right away. If you already are, make sure you’re including the hooks for monitoring, performance evaluation, and health checks as well.

What do you think about including DevOps into the definition of DONE? Are you going to start including post-deployment requirements in your definition of DONE?

 

versionone-coaches-steve-ropaSteve Ropa
SAFe Agilist, CSM, CSPO, Innovation Games Facilitator
Agile Coach and Product Consultant, VersionOne

Steve has more than 21 years of experience in software development and 12 years of experience working with agile methods. Steve is passionate about bridging the gap between the business and technology and nurturing the change in the nature of development. As an agile coach and VersionOne product trainer, Steve has supported clients across multiple industry verticals including: telecommunications, network security, entertainment and education. A frequent presenter at agile events, he is also a member of Agile Alliance and Scrum Alliance.

Posted in Agile Adoption, Agile Development, Agile Management, Agile Project Management, Agile Testing, DevOps, Uncategorized | 5 Comments

Empathy Driven Development: Rescuing Value from the Bermuda Triangle

Slide02Embarrassing Discovery

True story from when I was an agile coach for a multi-billion dollar, Fortune 15 giant…

It was a large agile program and we had new team members joining the program in waves. Not everyone was familiar with agile and we did not have money for in-person training. So we had to do the next best thing – remote agile training. Ugh!

Anyway, so I designed five 90-minute modules and as I was introducing the concept of optimizing value and minimizing waste, I asked the attendees who our customers and end users were and how our program helped them be more successful.

Nothing. Crickets.

I made an embarrassing discovery – most of the attendees were unaware of the “who our end customers and end users were.” Application architects, ScrumMasters, developers. This made it hard to talk about value and waste.

Course Correction

I was disappointed in myself. I had let my team down. So we worked with our product owner to shoot a series of videos that answered key questions about our business, our customers, our end users, their pain, what made them successful, and where our program fit in. We made these videos available on our team Sharepoint and made it mandatory viewing as part of onboarding.

A few months later, as I was walking around the office, chatting with some new team members, I asked the same questions – who were our customers and users, what were their pain points, where did our program fit in? I got great answers. No more crickets.

Tram-Scrum

This got me thinking about how frequently we get sucked into the mechanics of Scrum – the events and artifacts, without reflecting on the business value we were chartered to create. I call this TRAM-SCRUM where TRAM stands for:

  • T-actical
  • R-itualistic
  • Am-ateur

This was not why Jeff Sutherland and Ken Schwaber created Scrum. They wanted us to use Scrum strategically and professionally. I learned more about professional Scrum in the Scrum.org Scaled Professional Scrum course in Boston last year, but that is another topic for another blog.

I began wondering about some of the most common obstacles that prevented teams from making the shift from TRAM-SCRUM to PROFESSIONAL SCRUM. One common pattern kept niggling away at me – the lack of stakeholder empathy.

The Bermuda Triangle 

Our industry still suffers from the curse of the Bermuda Triangle – the place where all stakeholder value goes to die. This triangle is a crafty chameleon and seems to have changed forms over the years, but you know what Shakespeare said –

“A stinky diaper-genie by any other name would smell just as stinky.”
– William Shakespeare

Or something to that effect, anyway. English literature never was my strong point.
But I digress. Even though we have migrated to the rituals of Scrum, in many cases, we still labor under the tyranny of the Iron Triangle of staff, schedule and scope, we just rename the sides to be more “agile”…

Slide04

 

 

 

 

 

 

 

Cost Thinking vs. Value Thinking

So how do we stop getting more efficient at delivering waste and get more efficient at delivering value? This is another lesson I learned in the Scrum.org Scaled Professional Scrum Course

Slide05

 

 

 

 

 

 

 

STEP 1: Let go off cost thinking – How can I relentlessly cut costs, without factoring in the unintended destruction of value.

STEP 2: Take baby steps towards value thinking – how can I increase delivery of stakeholder value at the lowest cost, to generate sustainable stakeholder value?
I think one of the barriers to making this shift is lack of stakeholder empathy. Which brings us to the question what is empathy…?

Empathy

Empathy can be defined as…

“The action of understanding, being aware of and being sensitive to the feelings, thoughts, and experiences of another.”

Slide08

 

 

 

 

 

 

 

It requires us to walk in another’s shoes…

Current State

So this might open up an avenue of exploration for you – what is the current state of empathy in your teams, when it comes to your stakeholders?

We must begin by creating a shared understanding of who your stakeholders are. They might fall into different buckets…

  1. SPONSORS: Fund the Scrum team
  2. END USERS: Use the increments
  3. END CUSTOMERS: Served by end users via the increment
  4. COLLEAGUES: Impacted by the Scrum team
  5. EMPLOYERS: Writing the paycheck
  6. COMMUNITY: In which the team works
  7. OTHER: …?

What indicators might you use to assess this state? Are you satisfied by the current state, or would you like to make any adaptations? And if you would like to make some adaptations, what might you do…?

A Fresh Approach

I humbly offer to you an idea that has been evolving in my mind for about a year or so – drum-roll please….

Slide10

 

 

 

 

 

 

 

Empathy Driven Development

An approach to developing software that relies on team members making decisions based on empathy towards impacted stakeholders.

This approach requires development teams to creatively self-organize within the constraints of their organizations, to work around the barriers that isolate them from their stakeholders.

Empathy Driven Development (EDD) is complementary to agile software delivery with Scrum and is key to Scrum activities and events like backlog management and refining, sprint planning, daily Scrum and sprint review.

Common Barriers to EDD

As you think about using this approach, chances are that you will encounter some common obstacles…

  • Stakeholders inaccessible to development team
  • Un-validated assumptions about stakeholder needs
  • Layers of proxies between stakeholders and development team
  • Distrust between stakeholder proxies and development team
  • Cynicism / apathy towards stakeholders
  • No time / money to connect with stakeholders

If you are not ready to give up, here is a place to start…

Stakeholder Empathy Map

Get your team together in a room and…

  1. Create a grid with flip charts and tape.
  2. In the first column, ask your team to put post-it’s for all your stakeholders. Review and refine as a group.
  3. Now, ask your team to put up post-it’s to capture in 140 characters or less, each stakeholder’s…
  • ACCOUNTABILITY: What outcome are they responsible for?
  • MOST VALUABLE: What do they consider to be most valuable in the software they use, to help them deliver on their accountability?
  • MOST PAINFUL: What do they find most painful and frustrating in the software they use to deliver on their accountability

Review and refine as a group.

For instance, if we were doing this exercise in a group that develops patient care software used in a hospital, the outcome might look a little bit like this…

Slide13

 

 

 

 

 

 

 

Desired Outcomes

Whenever I have facilitated this exercise, it has generated tremendous conversation among the team members, which is the desired outcome. We want this exercise to result in…

  • Good conversations
  • Identifying Un-validated assumptions
  • Head scratching
  • Curiosity
  • Action items to connect with stakeholders
  • Many follow-up actions and conversations

But most importantly… an increase in stakeholder empathy!

Head vs. Heart

As you explore this further, an approach that might help you facilitate the enquiry is a pattern described by Dr. John Kotter, international change leadership guru, Harvard Business School professor, and founder of Kotter International. In his book – The Heart of Change -Dr. Kotter illustrates one of his Six Key Principles

Head and Heart. Dr. Kotter’s research demonstrates that successful large-scale change requires engaging not just the minds of those we lead, but, more importantly, their hearts. Creating a vivid picture of opportunities ahead is vital. A heartfelt passion and commitment enables companies to overcome the inevitable barriers and obstacles encountered along the way to success.

Slide16

 

 

 

 

 

 

 

Try to apply Dr. Kotter’s principle to establish an emotional connection between your team members and your stakeholders.

Self-Organization 

Challenge your teams to self-organize within the constraints of your organization to increase stakeholder empathy. Here are some initial ideas to get the ball rolling…

  • Try to get your developers to customer site…? (Make sure your most influential / cynical team members participate.)
  • Try to get customers to developer sites.
  • If you don’t have money, video customers using product and share it on your team site.
  • Maybe you can Skype / GotoMeeting with Webcam and watch your customers use your product and get frustrated or delighted with it.
  • Maybe you can include all these videos in new hire training / onboarding.

No matter what your team does, it must capture the smiles and frowns of your customers and stakeholders so it tugs at the hearts of your teams.

Call to Action

So here is my call to action – begin using EDD right now….

  1. Apply empiricism
  2. Create an empathy map
  3. Interact with stakeholders face to face or webcam. Make sure to talk to them and they are talking to each other.

Walk in their shoes. Self-organize and figure it out…!

  • TRANSPARENCY: Current state of stakeholder empathy
  • INSPECTION: Is it where you would like it to be?
  • ADAPTATION: Self-organize to make it better!

Rescue value from the Bermuda Triangle of cost thinking and value destruction!

And don’t forget to let me know how it goes.

Keep calm and scrum on!

Slide20

Posted in Agile Development, Agile Leadership, Agile Management, Agile Project Management, Agile Teams, Scrum Development, Scrum Methodology, Uncategorized | 2 Comments

10 Benefits of Agile You Definitely Don’t Want to Miss Out On

PrintAre you sure you’re receiving the most benefits of agile possible? Do you know the top ten benefits of agile?

Read this article to learn what nearly 4,000 of your agile peers said were the benefits of agile that their organizations are receiving.

 

#1 Ability to Manage Changing Priorities

According to the 9th annual State of Agile™ survey, 87% of the respondents said agile improved their ability to manage changing priorities. If you’re familiar with the Agile Manifesto, this likely resonates with one of the values: Responding to change over following a plan. This value was, in fact, probably the foundational reason for the agile movement, and its top ranking in the State of Agile survey reinforces the value of agile.

There’s no question about whether adopting agile practices will enable you to better manage changing priorities. The fact that you have product backlogs that are being ranked by product owners as information becomes known improves your ability to manage changing priorities. Planning is continuous and each sprint is an opportunity to revisit priorities based on feedback and insight gained.

#2 Increased Team Productivity

Approximately 84% of the survey respondents stated that agile increased team productivity. Increasing team productivity has a lot to do with getting employees engaged and focused. Employee engagement comes from having a sense of purpose. Fostering employee engagement and team productivity are a natural byproduct of adopting agile.

When practicing agile the product owner works from a set of overarching initiatives and a vision for the product. The product owner communicates the vision and value-based decisions to the team on a regular cadence as they plan each sprint cycle. This makes it very clear to a team practicing agile that what they’re producing in every sprint cycle is always of the highest value. The team is protected from outside interference to minimize context switching and multi-tasking, so they can remain focused on completing the sprint plan. Agile retrospectives and continuous improvement initiatives further improve team performance.

#3 Improved Project Visibility

Another 82% of the respondents answered that agile improved project visibility. Personally, as a former manager, improving project visibility would be a top agile benefit for me. Agile provides all stakeholders, team members, the product owners, and management real-time access to the health and status of all of projects. There is no need to wait on formal weekly, monthly, or quarterly status updates. It’s simple to instead check the project or sprint level burndown and burnup charts and you can apply velocity for project forecasting analysis.

As agile teams are updating the work they’re doing on a daily basis, the entire enterprise is aware of the accurate, current status of all the work across all of their projects. It’s simple and easy, with the added benefit that the story and task boards provide the teams with a visible information radiator that promotes team collaboration.

#4 Increased Team Morale/Motivation

The survey found that 79% of respondents to the 9th annual State of Agile survey increased team morale/motivation through agile. I think that increased team morale is tied to many of the same factors that help with improving productivity. Team members feel more pride and satisfaction in knowing that they’re delivering valuable quality work that somebody wants and appreciates.

Increased transparency in agile reduces a lot of stress and pressure. Agile allows organizations to break some of the political dysfunctions. As self-managing teams, members have a direct voice in planning and can take ownership of their commitments, thus making team members feel more connected. As an added benefit, working with a happy team is fun and promotes growth and skill development.

#5 Better Delivery Predictability

In the survey, 79% of the respondents stated that agile provided better delivery predictability. This emerges as organizations become more experienced at practicing agile. It’s important to realize that you don’t achieve better delivery predictability from day one. You have to be practicing agile for a few sprint cycles, and there has to be a certain maturity that’s established across the project teams. Over time, as your teams continue to practice agile and begin to stabilize, their velocity metrics are going to emerge and stabilize.

Velocity is what enables agile organizations to better deliver predictability. In the past, project managers tried to forecast and lay out plans in an attempt to predict the future. As hard as we might try, we can’t control the future, so often those results were less than effective. An agile organization is going to use an actual proven measure, such as velocity, and they’re going to apply that to relative size estimates of their backlogs.

#6 Enhanced Software Quality

Another 78% of the respondents answered that agile enhanced software quality. We coach agile teams not to compromise quality in order to make up for time or scope. An organization can never really achieve the optimum benefits of agility if they’re not addressing the underlying quality of their product or service, as well as actively managing technical debt. It’s instilled into the agile principles and values that teams estimate and plan accordingly to build a quality product.

Oftentimes, with traditional waterfall approaches, there are schedule pressures that can lead teams to feeling that they have to compromise quality. If the team has a fixed scope and is pressured to deliver by an unrealistic fixed date, the team doesn’t have a choice but to compromise quality.

An agile team, however, isn’t pressured to make those choices. Quality is a recognized commitment by these teams. While the results may not be visible immediately, over time, as the culture changes, inevitably teams will produce higher quality product leading to customer satisfaction and more sustainable scalable products.

#7 Faster Time to Market

The survey results reflect that 77% of the respondents said that agile provided faster time to market. A desire to get to market faster is a very common reason that businesses initially decide to adopt agile. Organizations are feeling competitive pressures and the need to improve their product faster to stay relevant. If another company gets to market with something better, they can lose significant customer share.

I’m a little surprised that faster time to market isn’t higher up on the list. I suspect that maybe this is because it’s something that is not necessarily inherent in agile planning practices alone and may not be fully realized initially. Yes, our teams are going to focus on delivering working software on a short cadence and getting feedback early and often, but there may some additional factors that come into play before software can be deployed into the marketplace.

#8 Reduced Project Risk

According to the 9th annual State of Agile survey, 76% of the respondents said that agile reduced project risk. Practicing agile reduces project risk by the very fact that agile organizations are conducting very short feedback loops, typically every two weeks or less. Agile teams are presenting results and getting feedback from the stakeholders in short sprints. That in itself reduces risk because unforeseen issues are discovered early when they can be addressed with less impact.

Additionally, in some cases teams are encouraged to rank known high-risk items so that they can work these items sooner rather than later, to address what they learn earlier in the project. This helps teams evaluate the risks earlier and discover whether or not the project is going be viable and deliver the expected value. If needed, you can redeploy these teams to work on something else that will deliver better value.

#9 Improved Business/IT Alignment

Among survey respondents, 75% of the respondents said that agile improved business/IT alignment. I often hear improve business and IT alignment cited as a main reason to adopt agile. This is realized through the closer collaboration that is inherent in the agile principles and values, primarily through the transparency and the feedback from short inspect and adapt cycles. I think this is a clear benefit that’s easily realized as teams are aligned to have more open and transparent collaboration between their product owner, who serves as proxy for the customer, and business stakeholders. Defining and communicating clear project vision drives this alignment.

#10 Improved Engineering Discipline

Another 72% of the respondents said agile improved engineering discipline. Improved engineering discipline is, again, not something that’s inherently obtained just by the fact that you adopt agile planning practices. When the expectations and the cultural underlying principles of agile are taken to heart, team members are empowered to address the delivery of quality work as opposed to just getting work done. The ultimate foundation of a good solid product is going to be inherent with a good scalable design and architecture.

Once agile organizations come to embrace the agile principles with a goal of delivering high product quality, they must also embrace sound engineering discipline. Effective design, configuration management and testing strategies are essential to maximize agility.

Conclusion

These results show that there isn’t just a single benefit of agile. Different organizations and teams are gaining different agile benefits.

Would you like to find out even more information about the benefits your peers are receiving? Check out the 9th annual State of Agile survey.

State of Agile is a trademark of VersionOne, Inc.

versionone-coaches-jo-hollenAbout the Author
Jo Hollen
SAFe Agilist, CSM, CSP
Agile Coach and Product Consultant, VersionOne

Jo Hollen has more than 30 years of experience in the aerospace industry. Her career began with training Space Shuttle astronauts. Jo later moved into software engineering management where she introduced agile practices for Mission Control Center applications, including software currently onboard the International Space Station. With a passion for continuous improvement and challenging the status quo, Jo believes that servant leadership and agile principles and values just make sense and welcomes the opportunity to help organizations optimize their effectiveness.

Posted in Agile Adoption, Agile Benefits, Agile Development, Agile Management, Agile Metrics, Agile Project Management, Agile Teams, Enterprise Agile, Scaling Agile, Uncategorized | Leave a comment

The Critical Aspect of DevOps You’re Overlooking

shutterstock_95440231DevOps tends to be viewed through a technical lens, but the people aspect is what will dictate your success or failure.

So, how are the people challenges of DevOps more important than the technical challenges?

Recently I was reading Puppet Labs’ State of DevOps Report. Similar to VersionOne’s 9th annual State of Agile™ survey, this report has an interesting set of conclusions about the current state of DevOps. One of the things that I’ve been considering for some time is the strange proximity of DevOps people to technical problems.

There are a lot of technical aspects to doing DevOps. One example is continuous integration. When releasing, everything needs to be integrated and checked, no matter how small. DevOps takes it one step further with continuous deployment since you need to set up acceptance tests and unit tests, and all tests have to be automated.

One of the aspects of DevOps that reading this survey reinforced for me is that the folks who do DevOps the most successfully focus on the people aspect as much as, or sometimes even more than, the technical aspect. This brings the Gerry Weinberg conundrum to mind. Gerry Weinberg, considered by some to be the grandfather of agile, said that there’s always a people problem. The technical focus of DevOps may lead you to think that there isn’t a people aspect to focus on. In reality, while the technical piece is a focus, the people problem is huge and even more important.

DevOps is about bringing the functions of operations and development together, which means you have to break some stereotypes. You have to think outside the box. Those on the DevOps team must have the will to think about each one of the development stories through the post-deployment lens. Do you have monitoring as part of what you’re doing? Do you have performance constantly tested? Do you have all aspects of your tests automated? If not, then you’re probably not going to be as successful with DevOps.

This sounds technical, but it’s actually more of a people problem. It’s employing DevOps engineers who remember to do that. It’s not asking the question of should you automate, but how will you automate this specific story? That’s huge and it’s vital. It needs to be addressed and it needs to be addressed successfully. If you don’t, then you’re not tall enough to ride the ride. It’s not worth your time and energy to claim to be DevOps if you can’t do those things. DevOps takes time, energy and nurturing. It takes the willingness for individuals to step up. And it takes the willingness for management to step back and give your people the opportunity.

There were a couple of other fascinating people issues that that survey brought to light. The number one key to success in an IT organization, according to this survey, was employee happiness. This is an aspect people need to listen to this and build on. Employee happiness is number one. It proves that even geeky programmers like me don’t derive our employee happiness only from the really cool tools we get to use and work on. It’s nice, but it’s not enough.

The other fascinating people issue was getting the whole team together to work on the issues, thus becoming a cross-functional team. Everybody is responsible for everything, and that makes a huge difference in the DevOps world, even more so than in the traditionally agile world. Teamwork is where you’re really going to see the difference between just checking things in all the time and continuous deployment.

DevOps lends itself to being viewed through a technical lens, but the people aspect is what differentiates you from success or failure. I hope I have inspired you to take a closer look at how you are balancing the people aspect of DevOps with the technical.

So, what are some other people aspects of DevOps that should be focused on?

Need assistance with a Continuous Delivery/DevOps Assessment? Click here for info.

VersionOne and State of Agile are registered trademarks of VersionOne Inc.

Posted in Agile Project Management, Agile Teams, Continuous Delivery, Continuous Integration, DevOps | 1 Comment