Feed aggregator

Test Automation Patterns: Issues and Solutions

Agile Connection -

Automating system level test execution can result in many problems. It is surprising to find that many people encounter the same problems yet are unaware of common solutions that worked well for others. These problem/solution pairs are called “patterns.” Seretta Gamba recognized the...

Lightning Strikes the Keynotes: STARWEST 2014

Agile Connection -

Throughout the years, Lightning Talks have been a popular part of the STAR conferences. If you’re not familiar with the concept, Lightning Talks consists of a series of five-minute talks by different speakers within one presentation period. Lightning Talks are the...

RallyON 2015 Keynote: Dan Pink on "The Cascade Effect"

Rally Software - Agile Blog -

We talk about how change is happening faster than ever, but that doesn’t mean we need to push change via massive, top-to-bottom initiatives. We see it happening in far more dynamic ways, and so does Dan Pink, one of our exciting RallyON!™ 2015 keynote speakers.

Dan’s presentation, “The Cascade Effect: How Small Wins Can Transform Your Organization,” will cover the complicated nature of change, how it really happens in an organization, and why small increments can have a big impact — especially when it comes to delivering at the new pace of change.

Dan Pink is a recognized author of five provocative books –– including best-sellers in the New York Times –– but his influence extends well beyond his writing. As a speaker, he focuses on behavioral science and has delivered more than 1,000 lectures. Dan’s TED Talk, “The Puzzle of Motivation,” has garnered more than 13-million views.  

Don’t miss this opportunity to think differently about how you can affect change within your organization and beyond. Register now for the RallyON 2015 Agile conference — three days of learning, inspiration, and fun with your peers and some of the brightest minds in the industry. Explore our agenda to view everything happening and you can even drill down by track to find the specific sessions that interest you most.

Hope to see you in Phoenix, June 15–17.

Morgan Campbell

10 Agile Books You Should Read This Summer

VersionOne Agile Management Blog -

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.

Scrum: 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

The 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

Agile Change Management:
A Practical Framework for Successful Change Planning and Implementation

By Melanie Franklin

The concept of agile working has been adopted by many organizations that recognize the need to respond quickly and easily to new opportunities in a world of complex and continuous change.

Agile Change Management offers best practice advice for planning and implementing change projects. Concrete tools help deliver projects successfully and realize benefits earlier on in the process.

By emphasizing and encouraging collaborative practices, the book illustrates how to build trust, influence and motivate others, and create a roadmap that outlines all the processes, activities and information needed to manage any type of change initiative. With advice for creating the right environment for change the book explains: who should be involved at each stage in the life style cycle, what tasks need to be completed at each stage, the concept of change in both large scale transformational programs and micro-level business projects, and the needs and benefits behind change strategies.

Along with a practical toolkit of materials available both online and in the book, Agile Change Management is essential reading for anyone who wants to develop the competencies of an effective change manager working in any project or program.

*Book description from Amazon

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

Agile 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

Agile 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

Agile 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

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

Agile Project Management with Scrum (Developer Best Practices)
By Ken Schwaber

The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But Scrum’s simplicity itself—its lack of prescription—can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and failures—culled from his years of experience coaching companies in agile project management. Through them, you’ll understand how to use Scrum to solve complex problems and drive better results—delivering more valuable software faster.

Gain the foundation in Scrum theory—and practice—you need to:

  • Rein in even the most complex, unwieldy projects
  • Effectively manage unknown or changing product requirements
  • Simplify the chain of command with self-managing development teams
  • Receive clearer specifications—and feedback—from customers
  • Greatly reduce project planning time and required tools
  • Build—and release—products in 30-day cycles so clients get deliverables earlier
  • Avoid missteps by regularly inspecting, reporting on, and fine-tuning projects
  • Support multiple teams working on a large-scale project from many geographic locations
  • Maximize return on investment!

*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?

Take an Agile Road Trip With Us!

Rally Software - Agile Blog -

Change is happening fast and furious in the business world. With so much pressure to keep up, it can be hard to take your foot off the gas pedal, even for a few days. Occasionally, though, it’s important to pull over and check the map to make sure you’re still on the right road.

If you’ll excuse the extended metaphor, we’d like to humbly offer RallyON!™ 2015 as a rest stop on your way to business agility.

Register today for the RallyON 2015 Agile conference — and get ready to drive at the new pace of change. Join us as we condense the industry’s most dynamic ideas, strategies, and practices into three days of learning, inspiration, and fun.

When: June 15–17, 2015

Where: JW Marriott Phoenix Desert Ridge Resort & Spa in Phoenix, Arizona

Don’t miss this chance to connect with experts and peers. It’s a rare opportunity to gather fresh insights that will remove your most challenging roadblocks and push your projects forward!

  • See how organizations like yours are achieving outstanding business results using Lean, Agile, and DevOps practices.

  • Learn how to create an unstoppable delivery engine, with coordinated teams using the coolest new collaboration tools.

  • Find out how to amplify the success of your Agile release planning and quarterly business steering to deliver value at scale.

Special Discount

There’s something for everyone, so bring your colleagues! In fact, when you register as a team, you can save up to 30% off the registration cost. See Pricing for more details.

Who’s Coming to RallyON?

C-level executives who need business agility to stay ahead of rapid change — whether it’s competition, disruptive technologies, rising consumer demands, or changing regulations

VPs and managers in development and product management who need to improve planning and coordination across teams, so they can connect strategy with execution and ultimately deliver business value

Development team members who are tired of fighting fires and want to gain visibility into work, balance priorities, and respond effectively to the needs of the business

Check out the agenda and search by track (we’ve got seven) to find the sessions that interest you most.

Don’t wait any longer. Register your team today!


Morgan Campbell

Pop Quiz: How’s Your Agile?

Rally Software - Agile Blog -

Humans typically crawl before we learn to walk, and walk before we learn to run. But sometimes what we call running is really more like a walk, and sometimes when we’re in a real hurry we’ve been known to skip a step.

Creative Commons photo via Flickr

How we learn to get started with Agile can take a lot of forms. Many people begin with baby steps: piloting a single team or experimenting with daily standups. Others are eager to get into a fast cadence right away and launch whole delivery groups — coordinated teams working on business strategy — all at once.

How we gauge our speed and progress varies, too.

  • Some organizations outgrowing stickies on a whiteboard don’t know how to take the next step.
  • Some go through the motions of Agile without noticing that their form is pain-inducing, or they’re moving so fast that they don’t have time to look around for competitors.
  • Some become so focused on the work in the moment that they lose sight of the finish line altogether.
  • Many who are “winning” at Agile forget to retrospect on their success or how to further improve.

Where are you in your Agile journey? Are you eager to take the next step, but don’t know where to start? Do you wonder how you stack up against others?

Now you can find out. Take five minutes to take our Agile Quiz. Get immediate answers, see how you compare to others who do what you do, and get recommendations for what to do next.



Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and Its Four Planning Objectives

VersionOne Agile Management Blog -

In the first blog post of this series of six, I explained the need for Agile Planning Framework with its four planning levels.

In this second blog post, I explain four objectives at each planning level, and how to use the proposed Agile Planning Framework to implement and operationalize your customized agile planning playbook.

Agile Planning Framework: 4 planning levels x 4 planning objectives covering 16 practices.

Table 1 presents the recommended Agile Planning Framework, with four agile planning levels represented by its four columns, and four key objectives represented by its four rows.  The wording of each objective is the same for all four levels, offering a unified treatment of each objective at all four levels, and also making the objectives easy to understand and manage.  However, the implementation of each objective with specific practices depends on the level.  For each of the four objectives, there are four practices corresponding to four levels of planning.  Altogether there are 4 x 4 = 16 practices covering all four levels of planning and four objectives. These 16 practices are numbered as 1.1 through 1.4, 2.1 through 2.4, 3.1 through 3.4, and 4.4 through 4.4.

Table 1: Customizable Agile Planning Framework with 4 Levels,
4 Objectives and 16 Practices

Objective 1 – Choose and include appropriate method for planning in your Agile Planning Playbook:  At each level of planning, Row 1 of Table 1 shows which specific planning method to choose from a set of choices, what specific things to pay attention to, and things to avoid as they cause waste.

Objective 2 – Obtain required inputs for planning and do necessary preparation ahead of the planning sessions:  Agile planners must obtain the inputs required for planning and do the necessary planning preparation ahead of each planning session (meeting or workshop).  Organizational old habits and inertia might mean multiple reminders and follow-up with at least some people, which some planners may find distasteful (pulling the teeth experience), and may be tempted to skip this diligence.  Without required inputs needed for planning and preparatory steps completed, the planning work to be done during a planning session will not be effective. Row 2 of Table 1 lists the input information needed for planning at each level.

Objective 3 – Develop your agile plan:  At each level of planning, several outputs must be produced to develop the Agile Plan at that level.  Row 3 of Table 1 lists many of these key outputs of the agile plan at each level of planning.  Note that the agile plan also needs to specify how workflow against the plan will be monitored.

Objective 4 – Re-plan as required, and improve the agile planning process and agile planning playbook on an on-going basis:  An agile plan is not an end-all in itself.  As an agile plan gets implemented at each level, lessons are learned through experience, and new inputs are received from the environment (market changes, competitive changes, and business condition changes), the plan itself will need revisions (agile re-planning).  The nature and method of re-planning change with the planning level.   The need for re-planning must be understood by the highest level of management – an area where agile champions and coaches may need to put some effort to overcome old mindsets.

Lessons learned from developing and executing agile plans at all levels, lessons discussed at reviews and retrospectives at all levels, and inputs received from the environment should become the basis for on-going improvements of the agile planning process and the agile planning playbook at your organization.

Relationship among Agile Planning Framework, Agile Planning Playbook, Agile Plans and their Implementations

Figure 3 shows this relationship along with an explanatory legend.  I encourage agile champions to use the Agile Planning Framework presented in this blog series (Blog 1 and 2) to guide the development of your customized Agile Planning Playbook.  Customization is done in the way you choose planning levels and planning objectives, and implement 16 practices of Table 1.  Agile Planning Playbook is part of the more comprehensive Agile Lifecycle Playbook.  Four planning level-specific playbooks are part of the Agile Planning Playbook.  Each level of planning provides the context for the next lower level of planning.  Implementation at each level provides feedback to the agile plan at that level, and based on the nature of the feedback the agile plan may be revised.

Moreover, implementation at each level provides a second order – what I call “derivative” – feedback to the Agile Planning Playbook; for example, if there is a systemic trend based on several days of daily feedback, it may alter the Agile Daily Planning and Daily Scrum Playbook.  As an example, if a team finds it difficult to hold to the scheduled start and end time of their daily Scrum meetings based on daily feedback from several days of work, then the team tries to find the root cause, fixes it, and revises its own Agile Daily Planning and Daily Scrum Playbook.

If a team finds that the same problems have recurred few sprints later even after “fixing” them as a result of an earlier sprint retrospective, the sprint planners and agile champions must explore deeper over the feedback data from a series of sprint retrospectives (hence it is called derivative feedback), address the root cause, and revise their Agile Sprint Planning Playbook.  Feedback from few samples in agile implementation is usually enough to drive a change in the agile plan at that level, but it requires sustained or systemic feedback over several samples (derivative feedback) to warrant a change in agile planning playbook at that level.  Sometimes, a feedback at one level of agile implementation may be so strong that it could alter the agile plan at a higher level.  An agile implementation or a plan or sometimes even a playbook may be altered due to inputs from the environment (market changes, competitive changes, technology issues, business changes).  This is not shown in Figure 3 to avoid clutter and to stay focused on the relationship among Framework, Playbooks, Plans and Implementation effort.

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

About the Author
Dr. Satish Thatte

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.

Hybrid Agile Versus Agile

Scrum Alliance -

As a test and Agile consultant, I have come to realize the limitations of working in a supposedly "Agile" environment -- an environment some call "Hybrid" but that could be used to deliver business value incrementally, if properly coordinated.

Turn Up Your Agile Noise

Agile Connection -

Usually noise has a negative connotation, but in this sense, noise means something that increases the team progress (i.e., velocity) and output (i.e., quality). Chaos is the negative side of noise and decreases velocity. Teams should know the importance of agile noise and handle the chaos in a right way at the time of transformation. Let’s explore agile noise and its benefits.

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

VersionOne Agile Management Blog -

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.

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 flows in sequential stages: approve and fund, implement, deployed, and measure Return on Investment (ROI).   Work items are modeled as Initiative epics.  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 dpicboard.

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 these details in future blogs of this blog series.


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

Customer Spotlight: MongoDB

Rally Software - Agile Blog -

Occasional stories about Rally customers who are doing cool and interesting things.

Fast, flexible, and scalable is an apt description for MongoDB, the leading next-generation NoSQL database. The document-oriented database is used by the world’s most sophisticated organizations, from cutting-edge startups to the largest companies, to create applications never before possible at a fraction of the cost of legacy databases. Think Internet of Things, realtime analytics, and mobile apps — all part of a rapidly changing technology landscape that requires a thoroughly modern database.

Fast, flexible, and scalable is also an apt description for MongoDB, the company.

With customers all over the world, MongoDB provides 24/7 support and services from offices in Dublin, Palo Alto, New York, Amsterdam, London, Sydney, Hong Kong, and Singapore, just to name a handful. That’s 200 people, from solution architects and consultants to TechOps, IT, and Support teams.

And they’re doing an incredible job staying patched into the hive mind. Teams are collaborating across time zones, using Rally® Flowdock® as a kind of clearinghouse for support tickets, bug fixes, troubleshooting, and more, with integrations to GitHub and social media channels. We love that they used the Hubot integration to automate much of this back-and-forth through a bot called GladOS.

As Engineering Manager Jeff Yemin told us, “We use Flowdock as one of our primary communication tools across teams and offices to manage and discuss how our various systems are performing. It has enabled us to raise issues and discuss solutions faster, becoming a core solution we depend on.”

Great example of a company living out the principles they build into their product. Want to learn more? Read the case study.

  Jen Page

The cone of silence and related project management strategies

Alistair Cockburn -

Humans and Technology Technical Report TR 2003.01, Jan 1, 2003

A person managing a portfolio has the job assignment to keep an alert eye open to oncoming trouble and an educated eye open for opportunity, acting in time for both, prioritizing choices along the way.

Managing a project consists of exactly this. Whether the entire team shares the assignment, it is part of the team leader’s assignment or it is given to a dedicated role, whoever holds the assignment is supposed to detect and act on future hazards and opportunities. Only through some odd misunderstanding of project life has project manager come to mean “the person who orders the others around.” It should mean “the most alert and most proactive,” the person that responds effectively to signals. Perception and creativity are intrinsically linked to the job assignment.

As I searched out experienced project managers, especially those labeled “good” by their peers, their perceptiveness and creativity stood out clearly. I began cataloging some of the more interesting strategies that I had been using over the years, and discovered that I was not alone ; almost every team lead and manager has had to invent similar strategies in their “normal” project life.

This article is about one such strategy, invented during my third visit to a troubled project. The problem was completely standard — you will recognize it. If you have ever been a team lead, you have been there. I’ve been in this situation many times and never found a solution for it. The fact that we found a solution that worked this time is why I am writing this article. Of course, in retrospect, we found that many of us had naturally been using this strategy for years; but not having a name for it, we didn’t even notice it in our bag of tricks. The purpose of this article is to give a name and a setting, so you can apply variations of it yourself.

Before telling you the problem and its incredibly simple solution, I have to warn you: To pull off the solution, you need a supportive manager. Remember, a manager is supposed to act to avoid trouble and grab opportunity, balancing priorities? This is a story of how we got ourselves out of a tight situation, with the help of a manager who understood how to support her people. Please don’t write to me to say that you can’t apply this strategy because your manager won’t support this solution – a manager who supports her people in their assignments is the key ingredient to this strategy.

The Problem Setting

Jim is lead programmer and domain expert on a project of eight people (Jim, six other programmers, and Aaron, the project manager). Jim has worked on previous versions of the system. Mark has also worked on the previous system and has domain knowledge. However, he gets diverted daily from this project’s activity by a second boss he has. There is nothing we can find that will reduce the level of interruption he has from the other boss, so he pretty much gets washed out of the project in terms of effectiveness. The other five programmers, of varying abilities, have been added to the project to help Jim get the work done, mostly on the many little programming assignments that don’t need deep domain knowledge. Aaron was recently introduced to help offload Jim from bureaucratic work. Their manager is Lisa.

The six programmers work in partitioned cubicles in an area accessed by a short hallway. Jim sits in a private office coming off this short hallway. Aaron sits around the corner and farther down the main hallway.

Jim has this private office so he can close the door to get privacy, but otherwise be available to answer questions from the other programmers. At least, that was the big idea.

The idea backfires. Jim’s office is tiny, so he keeps it open a crack. Consequently, he sees everyone walking up and down the hall, and he gets asked questions multiple times an hour by the other programmers. He also gets visited or called out every time there is a question about either the schedule or the system architecture.

Oh, and of course, upper management decided to outsource future versions of the product, so Jim has to interface to and transfer knowledge to the outsource company. In short, like so many team leads around the world, he gets nothing done during the day, and is reduced to working nights and weekends. He has no spare capacity left, and is burning out, all without the project making headway.

In my first visit, we go over the project schedule, create a simplified project plan and determine three things. First, the team can’t get done in time. Second, the only person who can do most of the actual programming is Jim. Third, Jim is calamitously overworked. Note that it took most of Jim’s day to participate in this session, so he ended up one day behind for getting this information (all of which was obvious to start with, except for the simplified project plan). So far, this should like like very many software projects.

Attempted Solution #1

It is clear that Jim needs more design time and fewer distractions. So we make the usual promises.

We promise that Jim will not get disturbed for trivial issues. Aaron will take all non-technical interrupts, the new programmers will work together to train themselves on the domain, Mark will track and reduce his disturbances from his other boss (whom we cannot get rid of), and Jim will focus on his programming. He will only be interrupted for major questions.

Of course, this doesn’t work.

Jim’s office is small enough to be claustrophobic when the door is closed. Besides, he case hear people walking up and down outside his closed door, and he frets that something is going wrong that he should be attending to. He keeps the door open a crack.

The other programmers on the project just need to get their questions answered, so they ask Jim anyway.

Mark can’t do anything about his other boss, who, for reasons we needn’t get into, has the right to create high-priority interrupts multiple times a day, and does. In other words, he never gets sufficient time to offload Jim.

No matter how Aaron tries, there are still meetings that need Jim’s technical expertise on the project and scheduling matters. Jim still gets called out of his office, or the meeting comes to him.

The “obvious” solution isn’t working.

Attempted Solutions #2, #3

How about having Jim work at home? We try that, but it turns out that he doesn’t work well at home. Besides the set of distractions around his house, he can’t get the high-speed line he needs to link to the development environment. He has to work in the office.

There is one would-be strategy that usually doesn’t work but we have to try. It is Bundled Distractions (written with a line drawn through it, to show that it is a generally unsuccessful strategy). The idea is to create office open-hours for Jim, and have all questions and interruptions come in during those open hours. We decide that he will handle questions for half a day a couple of days a week.

As is usually the case, Bundled Distractions didn’t work. The team simply couldn’t hold themselves back from questions, Jim couldn’t hold himself back from being helpful.

Why do I bother to mention this strategy if it doesn’t work? I do so because it sounds so good, and so rarely works. In 30 years of project life including 10 years as a consultant, I have never seen it work on a project (although it seems to work with university professors). Nonetheless, it is a possible strategy, and we were desperate enough to try it.

Cone of Silence

Before giving up, we revisit the problem one more time:

Jim needs quiet time to focus, real freedom from distractions, and a high-speed connection to reach the development environment. He can’t work in his home or his office. In a reversal of the usual project priorities, it seems he can’t be close and available to his teammates, he needs to be invisible to them.

I ask one last time (I’m sure this suggestion got made and rejected at least once before in our deliberations) whether Jim couldn’t get a second office somewhere else in the building, far enough away that people won’t be bothered to walk that far to ask him a question, but where he still can connect to the office LAN and have the feeling of being at work. This would provide him with a “cone of silence” in which to get his work done.

Much to my surprise, Aaron, Lisa and Jim all say, “Yes, we could do that – that might work.” To this day, I don’t know why this suggestion didn’t get picked up the previous times it came up (I don’t know that it didn’t come up, I only suspect that it must have been suggested). I think that every strategy is appropriate for a particular level of desperation, and we were not desperate enough before to pay it any attention.

In any case, they get enthusiastic about trying the Cone of Silence, as the name sticks. I remain skeptical, because it seemed to me that Jim will get drawn into meetings just as much as before, but don’t say anything, because we really are desperate by this point.

What Happened

I didn’t see or hear from the team for several months. In a casual phone call one day, Lisa mentions, “Oh, that Cone of Silence is working really well.” Apparently, Jim really does go to that office, and other people don’t bother him. For the first time in over a year, he has enough quiet time to focus on his list of work. He concentrates, he is happy, he makes progress.

What about all the other people on the project, and all the distractions?

The others still have questions, and they entire team moves more slowly than before because their expert is gone, but they make adequate progress without Jim. Aaron and Lisa keep people away from Jim. Aaron steps in and makes project decisions mostly without Jim. Lisa reminds people of the project’s true priorities, which include Jim getting his work done as top priority, and almost everything else second to that.

More months went by, and I receive a call from Lisa again. Almost off-hand, she mentions that Jim is almost finished with his work, well ahead of the project plan we created on my first visit. I confess to be astonished by this news. My view was that that schedule was unduly optimistic. It seems, however, that Jim, a combination of domain expert and senior programmer, was able to move faster when left alone with his code than he predicted.

Why Did it Work?

What worked, and why did it work?

What worked was that Lisa, the manager above the project manager, correctly saw Jim’s progress as the single top priority to the project. Everything else was secondary. Unlike many managers, she was willing to bend rules to attend to satisfying this priority. She was able to find another office, and she kept everyone appraised of the importance of working on the other assignments without Jim.

I highlight Lisa’s role, because I have encountered many managers who insist on keeping everyone within their sight, who won’t go out of their way to get additional resources such as a second office for Jim, or who yield to pressure to bring Jim back to attend meetings and answer questions.

Lisa accepted that the rest of the team would have to “muddle through” without Jim; she correctly assessed that they would, in fact, be able to muddle through, though at a slower pace. Many managers would chicken out at the last instant and recall Jim.

What also worked was that Aaron, the project manager, supported Lisa in the strategy. He had to make himself conversant enough on the topics to make decisions along the way. Note that Lisa had to trust and support Aaron in getting to this level, and Aaron had to support the strategy in not running to Aaron with his questions. Aaron also had to keep the rest of the team from running to Jim.

Besides the level of support, there had to be a barrier, the Cone of Silence itself.

Normally, I recommend putting a project team close together, because research shows that generally, people won’t walk up a flight of stairs to get questions answered, or, as it turns out, even a couple of bends in the hallway [Allen98]. Normally, we want people to get their questions answered, and so we ensure there is no flight of stairs between them.

In this case, we needed that very barrier.

Strategies are Interlinked

Project management strategies do not sit in isolation. I wrote down a dozen strategies, lightly interlinked, in the appendix to Surviving OO Projects. I now find them heavily, not lightly, interlinked.

Osmotic Communication is a strategy is described at length in Agile Software Development. The idea is that teammates sit in the same room or adjacent cubicles, so that they overhear each other during their normal working day, picking up information in their background hearing. Even while not particularly conscious of it, they learn who knows the answers to which sorts of questions and what is happening on the project. They can ask questions without particularly raising their voice, and often can answer a question without particularly getting distracted from their current work. In the normal course of events, Osmotic Communication is the ideal. In our particular project, the Osmotic Communication was good for everyone except Jim. Cone of Silence__sets up the opposite dynamic to Osmotic Communication, sufficiently so that I will come back to these two in a moment.

Expert in Earshot is described in CockburnEiE]. The idea is that novice workers should work within earshot of an expert, in order to pick up good work habits. Like Osmotic Communication, the Expert in Earshot backfired in our situation, actively causing problems because the expert couldn’t get his work done. This backfiring is mentioned in the description of Expert in Earshot as the “overdose effect,” an apt description of what happened on this project.

Progress Team / Training Team is detailed in Surviving OO Projects, where it is given the cute primary name Day Care and the more descriptive name Progress Team / Training Team. I now think that the longer name is the better one. Cone of Silence implements Progress Team / Training Team, since the project needed Jim to make maximum progress, and the rest of the team was allowed to work at a slower pace as they learned their material.

Cone of Silence, then, permits Progress Team to be implemented, at the cost of Osmotic Communication with the expert. It is a deliberate move away from Expert in Earshot.

In general, I find that Osmotic Communication and Cone of Silence are two strategies that need to be balanced, usually with more of the former and only a little of the latter.

Variations on a Theme

A good strategy gets rediscovered many times. After we applied the Cone of Silence successfully, I searched for other situations and some varied ways in which it was done.

A similar implementation of the strategy. I was once in charge of a research project that ran with half a dozen people over a few years. Partway through, it became clear that we were a bit lost in terms of our project structure and plan. I made a deal with a sister organization to get use of a quiet office at their location for two days to rebuild the project plan — I had found our normal office environment too distracting to get two days of quiet time there. I sent an email to my boss, Elizabeth, on the Sunday night before I went, saying what I was doing. When I called in to the office to check for emergencies on the first day, my boss scolded me severely for setting up off-site work without her permission, and for disturbing the sister organization. What a difference between Lisa and Elizabeth! As you can guess, that destroyed any peace of mind I might have within my little Cone of Silence, and the two days were not as productive as I had hoped, although still better than staying at the lab.

A larger implementation of the strategy. I met a manager at a company that was having trouble adopting Extreme Programming. The company had a tradition of “off-sites,” which in their language meant that they moved an entire project team out of the office to a special off-site location for a short period of time — a weekend to two weeks — in order to make maximum progress on a targeted section of software. In the “off site,” they would set up Osmotic Communication and a Cone of Silence for the team. The odd part was that the resistance he ran into was that the people there considered XP as nothing more than extended off-sites, and they therefore wouldn’t try it! (The logic of that I leave as an exercise to the reader.) If their off-sites are so effective, I would think they would legitimize this setup as standard practice for all their projects. Can your organization manage to?

Two very large implementations of the Osmotic Communication with Cone of Silence combination were IBM’s development of the IBM PC in the early 1980s and Lockheeds Skunkworks facility following the second world war (nicely described in the book Skunk Works [Rich94]). In IBM’s case, the executives decided that they couldn’t develop the PC with the existing IBM bureaucracy and working style, so they shipped the team off to a warehouse to get some privacy, speed and informality in their work. Lockheed’s Skunkworks facility designed their most difficult, top secret military airplanes. They sat, deliberately crowded together, with different specialties within easy earshot of each other, in a facility cut off from outside distractions.

A small implementation of the strategy. I usually wear airport-style ear-muffs when I need to concentrate while working in a large room (18 – 20 db hearing protectors . . . I buy them at any local gun shop). I find that this cuts down the noise just enough that I can concentrate, but lets me hear if someone calls my name. I’ll take them on and off depending on how much concentration I need, thus balancing Osmotic Communication and Cone of Silence. Other people use music headphones to get the same effect. Sometimes they never hear their colleagues speaking, though, so they get too silence and not enough communication.


Why did it take so long for us to recognize and apply the Cone of Silence idea to Jim’s situation?

Partly, we hadn’t reached the appropriate level of desperation earlier. We worked through the easier alternatives first, because those would cause less disruption to the project. If one were to categorize the level of desperation as the levels of a fire alarm (one-alarm, two-alarm, three-alarm fires send calls to that many fire stations), then we might say that BundledDistractions and the other strategies we started with are applied at the one-alarm level. Isolating the team lead in a Cone of Silence is disadvantageous to a project under normal circumstances. Only when we reached the two-alarm stage was it a worthwhile tradeoff.

Also, these project management strategies don’t yet have an accepted set of names and study literature. Jim Coplien and I have been deliberately collecting these strategies for a number of years. Jim collects mostly organization patterns CoplienOP, I collect mostly risk reduction Project risk reduction patterns], but these are not yet at the stage where people look through them as standard problem-solving procedure. When I am in an optimistic mood, I think that this might change in another 10 or 20 years.

After we did apply it, why did it work?

It worked in part because people really do find a flight of stairs to be a considerable barrier to asking questions. It worked in part because Jim really could do his work in isolation.

The final, and in my opinion, most important reason it worked, is that his managers, Lisa and Aaron, were perceptive, creative and supportive.


Allen98: Allen, T.J., Managing the Flow of Technology, MIT Press, Boston, MA, 1984.

Cockburn98: Cockburn, A., Surviving OO Projects, Addison-Wesley, 1998.

Cockburn03: Cockburn, A., Agile Software Development, Addison-Wesley, 2002.

CockburnEiE: http://c2.com/cgi/wiki?ExpertInEarshot

CockburnPrrP: http://alistair.cockburn.us/crystal/articles/prrp/projectriskreductionpatterns.html

CoplienOP: http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?OldOrgPatterns

Rich94: Rich, B, Janos, L., Skunk Works: A Personal Memoir of My Years at Lockheed, Little, Brown and Company, Boston, MA, 1994.

Re: Crystal methodologies

Alistair Cockburn -

hello, i am a student. i am in the search of following questions? despit of other agile models XP, FDD, etc etc why another family of agile models named “crystal family” was needed? through different studies i am satisfied that “why to use agile process models” but still i can’t know that why crystal models? how crystal are more good than other agile models. kindly give me feed back. regards, Iram

Alistair’s reply: The Crystal family of methodologies was started in 1992, before XP, FDD etc. It was named “Crystal” in 1997, before the agile manifesto. It was one of the founding ‘agile’ methodologies.

It is different than XP or FDD because it is a family of methodologies, not just one.
I have a section on this question in more depth in the upcoming 2nd edition of Agile Software Development due out Nov 2996.

From that book, “A named methodology is important because it is the methodology author’s publicly proclaimed, considered effort to identify a set of practices or conventions that work well together, and when done together, increase the likelihood of success. [and later…] Crystal is my considered effort to construct a package of conventions that raises the odds of success, and at the same time the odds of being practiced over time. ”


-by Iram on 12/13/2008 at 12:06 AM

What if I don’t want to wait another 988 years for your book to come out? ;-)

-by Immo Huneke on 1/20/2009 at 3:55 PM

Nice. :). It seems I managed to get a bit ahead of schedule, and got the book out already in 2006. Whew, imagine you were going to wait 988 years to read it – I was going to have to be 1,042 years old to write it!

-by Alistair on 1/20/2009 at 10:52 PM

If you were to do a “compare and contrast” with the Poppendieck’s Agile Toolkit, what would be the key points?

-by Wade on 3/19/2009 at 4:50 PM

I’m a student from China. Greetings.

I’m not totally understand Crystal Methodology

can you give me more details on it such as the lifecycale model of it.

regards Newman

ps.It will be very nice of you to send me an E-mail because in china when you open a web page of other contries it will be incredibly slow.

-by 夏宜蜜雪 on 3/22/2009 at 10:13 AM


-by 夏宜蜜雪 on 3/22/2009 at 10:14 AM

Very refreshing ideas indeed. Words such as non-jealous and just-in-time make perfect sense.
I understand that the aim of Crystal would be to provide a methodology aiming to create a per-project methodology. It’s just a matter of words but, would it be correct to assume that Crystal is more like a meta-methodology than a methodology ?

-by Antoine on 8/10/2009 at 6:06 AM

Hi, Antoine – You are right, in a wide sense.

A methodology is nothing more than “the conventions a group of people adopt”, a nice, simple definition that allows it to drift over time and be easily documented and easily changed.

Knowing that, how can I possibly write down in a book the conventions that every team on the planet should use?

So instead, I write down the parameters and principles I understand thet help people work together and tell whether their conventions make sense. The “Properties of Successful Projects” are the guideposts, the principles are the physics of teamwork, the techniques and strategies are industry lore.

So in this sense, yes, it’s meta to any specific team’s methodology.

Good eye.


-by Alistair on 8/11/2009 at 2:19 PM

Referring to the Agile Manifesto and values of valuing one thing over the other back in Feb 2001, I strongly believe that for any project people are very important but tool as well. I was reading an article defending the agile values, saying that tools are important but need people to operate. What about the people with out tools? I meant to say that aren’t they both have some importance in a project. Also working software over documentation. Documentation are considered to be overhead but what in case if the people working on the project are offered better job elsewhere and they leave the project with out documentation? Isn’t it the case if people are agreed to work till the delivery of the project and provide guarantee that they won’t leave until the project ends. I hope you will understand where I am coming from.

Secondly, does any of the agile methodology fits for any project. I mean like can the values and principles of methodologies be ignored if creating problems? Or in other words, is it practical to apply partial principles by omitting the one that don’t work for any specific case.

Thirdly, I was trying to evaluate the agile methodologies as was trying to find out their appropriateness for IT Projects? What can be the criteria for the evaluation and assessment of these methodologies?

Lastly, what can be considered as an international IT project? Is there any definition available which can distinguish international IT project? Please explain

I hope this would not be too much to reply.



-by Faisal on 9/15/2009 at 4:37 PM

no saben de algunos proyectos que usen estas metodologias?? y tambien que usen MétricaV3
gracias de antemano

-by yoci on 9/27/2010 at 6:52 PM

What are sample systems developed using crystal clear methodology????please answer…...

-by erdz on 1/9/2011 at 9:46 PM

me too i say it:

What are sample systems developed using crystal clear methodology???? please answer…...

-by Ruben Huanca on 11/14/2011 at 12:20 PM

15M$ fixed-price contract using Smalltalk, COBOL, DB2 in U.S., 50 people, 1994-5; Insurance claims system in Germany, 6 people, 1998-2003; French post office 2002-4, 24 people; Belgian post office 2004-6; Radiology imaging advisory system in U.S., 4-16 people, 2004-11. Others I don’t know of. Alistair

I used Crystal Clear to develop a couple of petroleum exploration systems. C++, 6-15 person-year projects.

-by Satoshi on 11/28/2011 at 4:18 AM


I’m currently working on a study about agile methods and their apllications. Would you say that agile methods and especially Crystal methods are limited to project issued of Software development? I would love to hear your opinion about that.

Thank you very much for your answer



-by Benjamin on 12/31/2011 at 1:11 PM

Hi, Benjamin; agile approaches, including and especially Crystal, have nearly nothing to do with software development specifically. It is just an accident of history that programmers articulated the properties of effective team design first. Crystal applies to nearly every group endeavor, with increasing relevance to team-based design, and eventually to software. Thanks for asking. Alistair

Hello and Happy New Year,

Thank you very much for your quick response, I would like to ask some more questions about Crystal methods and their applications to common project management. I would really appreciate it if you could find some time to answer 4 to 5 questions by mail?

Thank you very much in advance,


-by Benjamin on 1/1/2012 at 9:15 AM

Hi, Benjamin: I will if you read the book Crystal Clear first. I’m not interested in regurgitating in emails what I took a long time to write down carefully.

-by Alistair on 1/3/2012 at 1:19 PM

Hi Alistair,

Can you Provide me the one line definition of the following:

1. what is Agile methodology?
2. What is scrum methodology?
3. What is xp methodology?
4. What is Crystal Methodology?

I just want to know the answers of these questions because I appeared for an interview and these are the questions that I was unable to answers and for this reason I lost the job.
So, I want to know how to handle these questions in the interview. I mean what type of answer needs to be presented?


-by Rahul Sharma on 1/4/2012 at 2:00 AM

Hi Alistair,

Can you Provide me the one line definition of the following:

1. what is Agile methodology?
2. What is scrum methodology?
3. What is xp methodology?
4. What is Crystal Methodology?

I just want to know the answers of these questions because I appeared for an interview and these are the questions that I was unable to answers and for this reason I lost the job.
So, I want to know how to handle these questions in the interview. I mean what type of answer needs to be presented?


-by Rahul Sharma on 1/4/2012 at 2:06 AM


I fully understand your concern and I asure you that I already read a lot about agile methods and Crystal methodology in particular. I read your book about Agile Software Development (The Agile Software Development Series) and it helped me a lot for my study. I just have a few questions about how the flexibility of agile methods is working in practice in complex projects where documentation is important. I was also wondering if you would have maybe some feedback of agile methods beeing used in non-software projects?

Thank you very much,


-by Benjamin on 1/4/2012 at 5:40 PM

Hi, Benjamin, Rahul: I’m sorry, simple Google searches turn up answers for all these questions. Alistair

-by Alistair on 1/4/2012 at 8:28 PM

what is crystal? please explain and give me examples I Just want to understand it.

-by chris on 3/6/2012 at 10:56 AM

what is crystal? please explain and give me examples I Just want to understand it.

-by chris on 3/6/2012 at 10:56 AM

what is crystal? please explain and give me examples I Just want to understand it.

-by chris on 3/6/2012 at 10:56 AM

why is crystal called a family of agile methods?

-by chris on 3/6/2012 at 11:01 AM

Hi, does crystal have any forum o webpage support where I can find the “official” practices?
(like scrum.org for scrum )
Thanks in advance :)

-by Juan Daniel on 4/26/2012 at 11:12 AM

yes – the crystalclear forum on Yahoo: http://tech.groups.yahoo.com/group/crystalclear/

Dear Alistair,

You are a patient man. :) Thanks for all your work, which has been most informative to me.

-by Bob Rodes on 8/26/2012 at 11:53 AM

LOL, Bob – that may be the first time I’ve been called that! Thanks! :). Alistair

hi, i am a student in a project search. i want to know more about crystal clear and crystal orange in agile methodologies.

-by francis on 9/27/2012 at 6:51 AM

_The discussion group is at blank">http://tech.groups.yahoo.com/group/crystalclear/ ... hit the Join button and I’ll get a message w your email address and OK you for the group…. Alistair

Hi Alistair,

Just want join the group for another new project.



-by Blvette75 on 2/27/2013 at 8:49 PM

This is satire right? Please tell me this is satire. Or I quit the IT industry.

-by Erwin Katz on 3/8/2013 at 6:16 AM

Hey Alistair,

I did my math – you are 59 years old :) Am I correct ?

-by Saravana Bharathi on 8/21/2013 at 3:56 PM

Hey Alistair,

I did my math – you are 59 years old :) Am I correct ?

-by Saravana Bharathi on 8/21/2013 at 3:56 PM

what is crystal family methology?

-by bpt5s on 5/16/2015 at 6:52 AM

Failure Modes of an Agile Transformation: Workflow

Rally Software - Agile Blog -

In my previous post on the first three Agile transformation failure modes, I focused on the LEADERSHIP aspects of failure: lack of real executive sponsorship, failure to transform leader behaviors, and refusal to change organizational structures.

These next three fail modes are failures in WORKFLOW: effectively making work decisions flow, setting work boundaries, and factoring in the costs associated with work across distributed teams.

4. No Business View of the Value Stream

 photos via Flickr Commons 

Several years ago, I had the good fortune to work with Hendrik Esser in a weekend workshop. Hendrik and I converged on the value stream: What does it look like in traditional organizations? What might we want to be different? And how does an Agile transformation support or impede this new perspective? What we’d seen in our respective careers was frighteningly similar. Most organizations embraced silos, to the degree that even as they were adopting Agile practices, they did so in “agile silos.”

There was no view across the value stream. That is, these organizations weren’t tracking the “concept-to-cash” flow of value through a system.

Successful Agile transformations ask us to accept a few basic truths and practices about value streams:

  • You’ve got one; go find it.
  • Map your system at whatever level of detail best articulates your sense of handoffs and bottlenecks.
  • Start where you are in the value stream; taking on an entire system will exhaust you and your teams, which will lead to abandonment of the Agile transformation effort.
  • Every system has one primary constraint; find yours, crush it, and then look for the next primary constraint that emerges. Rinse and repeat.
  • Be ruthless in your vision to expand the boundaries of your value stream: upstream from the neighbor processes that feed your work, and downstream where you feed your work into your neighbor process.
  • Include everyone in identifying the value stream, its bottlenecks, and its potential flow.
  • Broaden commitment up and down the stream, not in localized silos.
5. Failure to Decentralize Control

In my previous post about leadership-themed failure modes, I mentioned the work of Robert Greenleaf. Among his 10 attributes of a servant leader, two of my favorites are acceptance and withdrawal. What do these mean to you and how to do they impact the success or failure of an Agile transformation? To me, these make me think of the experience as a manager or being managed. Here’s a little story about managing me.

Across my tech career I’ve worked for a variety of managers. In one job, I worked in a small group analyzing various methodology approaches for software development. This was exciting: it was my first foray into a break-up with waterfall approaches. Though rather shy (yes, me!) I was a sponge, passionate to contribute and engage. In one meeting, a particular issue was raised that related to the work I’d been doing and I offered up what I thought was a relevant solution. At a break in the meeting, my manager pulled me aside into a separate room. “Why did you disagree with me in there?” he inquired. “Don’t you trust that whenever I make a decision I’ve thought of all other possibilities? You’re disrespecting me.”


I’d like to say that was the only manager who has ever needed to have complete control over decisions, but you know better. In most cases, there are a few dynamics at work here:

  • The manager’s sense of significance is somehow wrapped up in the decision-making control.
  • Due to this strict, centralized control, decisions are not as informed as they could be.
  • Waiting for a decision because of centralized control wastes time and human potential.
  • This control style ultimately lowers morale and fosters cynicism.

Agile transformations fail when we don’t pay attention to whether we centralize or decentralize control. Greenleaf would characterize this as an inability to recognize when to accept the decisions of the team and when to withdraw your control so that the team owns decisions that impact their way of working. Servant leaders don’t relinquish all control; rather, they recognize the value in releasing control when all concerned are better served. They maintain centralized control when they see that this is in the best service to their teams.

Don Reinertsen talks and writes well about this (see The Principles of Product Development Flow.) You can use some simple guidelines to steer you towards appropriate control modes. Long-term decisions with extended impact that include dependencies across many constituents warrant a centralized mode of control. Short-term and low-impact decisions merit decentralized control. In Don’s words, think of these two principles:

  • The Scale Principle: “Centralize control for problems that are infrequent, large, or that have significant economies of scale.”
  • The Perishability Principle: “Decentralize control for problems and opportunities that age poorly.”

Agile transformations require continuous learning, and servant leadership is no exception. When Don talks about these domains of control, one thing is certain: this is not about controlling the worker. As he says,

“Watch the work, not the worker.”

Decentralize to move decisions closer to the worker, the one who best knows the work. Centralize control as a service to the flow of value. A bias toward decentralization helps leaders and teams better converge.

6. Unwillingness to Address Illusions Around Distributed Teams

More and more I’m seeing organizations with distributed teams: wide dispersement of teams across many time zones, and even 80/20 rules that guide projects to employ 80% offshore teams with only 20% of teams located in the same building (or the same city.)

Want to fail at your Agile transformation? It’s easy. Follow these simple rules for distributed teams: set up a complex geographic maze based on the economics of resource utilization; ensure a time zone difference between 7-11 hours; rely heavily on emails and large documents (especially detailed test plans) for your communication; and definitely don’t invest in bringing people together to collaborate or train.

Organizations in this distributed bind have essentially made deals with the devil, trading off fundamental Agile success principles like face-to-face collaboration for the promise of speed and lower costs (but don’t worry, it’s still Agile!)


How do you monitor the value stream and the flow of work? What working agreements and communication approaches have you implemented that work across cultures? How fast is the feedback? Where is the cost-of-delay calculation in your ROI equation? And perhaps most importantly, who’s representing the challenges of the distributed teams to the rest of the organization? Who listens to them when the constraints become overwhelming?

Here are some changes you can embrace to deal with the distress introduced by the distributed model:

  1. Hire a coach who’s well-steeped in distributed team success.
  2. Ensure all team members receive the same Agile training; for maximum effectiveness, get everyone in the same room for the training.
  3. Invest in high-definition, large-screen video technologies. Accompany these with a top-notch sound system that literally brings all the voices into the room.
  4. Have a facilitator in each location when teams plan their dependent delivery commitments.
  5. Whether using audio-only or adding video, use facilitation techniques that ensure all insights are welcome (small-group brainstorming, round robin check-ins, frequent breaks.)
  6. Invest in technologies that support transparent workflow communication — for example, Flowdock.
  7. Maintain a regular cadence of visits across all geographies and all roles.
  8. Build working agreements that support core hours for availability, or alternative solutions for quick turn-around feedback.
  9. Trade or share the burden of dealing with broad time zone differences.
  10. Engage the executive sponsor in regular visits to all locations.

Finally, here’s the one, most important practice I believe is critical to a distributed team delivery model:

Eliminate distributed teams.

That’s it. This yields the biggest success stories I’ve seen with distributed teams. Nearly everyone I talk to says this isn’t a choice for them; yet if they knew the amount of waste built into the distributed delivery model, they’d realize the irony of thinking it’s saving them value.

Stay tuned for the next in the series on the 12 Agile Transformation Failure Modes!

  Jean Tabaka

10 Agile Quotes From The World’s Most Brilliant Minds

VersionOne Agile Management Blog -

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









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.









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.








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.









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.









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.









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.









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.









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.









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.









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?

Re: What to do instead of bad responsive design

Alistair Cockburn -

So, to my mind something like twitter or kitkat.com do what I really want from responsive design: as I narrow my browser, they re-lay-out to fit everything in the new narrower space.
Are you saying that this is what you don’t like?

What I do find really irritating is sites following your unbroken-baguette example, overflowing the plate, so I have to horizontal scroll to read when I shrink the window.

I can see the 3-width shrink (desktop-tablet-mobile) being over-sensitive sometimes.

It’s true that e.g. alistair.cockburn.us/ also fits everything in a shrinking window without responsive design. But the text still has to move, so I still lose my place.

But to add ammunition to your cause: I see nothing ‘lazy’ in responsive design. It appears to take at least as long as doing two (or three) layouts + bugfixing the transitions.

-by Chris F Carroll on 5/13/2015 at 2:54 PM

What to do instead of bad responsive design

Alistair Cockburn -

What to do about bad Responsive design?

Short answer: Design for the device.

I get to use really good mobile apps – they are clean, easy to read, easy to use. (Examples abound. Orbitz is a handy one). Whoever designed those understood the medium, its affordances and limitation, and designed for that.

Big screen is different – different medium, different affordances. Good designs on the big screen are very different than good designs on the small screen.

Responsive design is the lazy designers way to make designs that fit no screen well. Kind of like 1-size-fits-all clothes that meet a person the right size by random chance.

The worst of responsive design is the big screen, with resizable browsers – every movement of the browser window changes the layout and what is visible. This can never be a good design.

What I would like to see is this :

- design for two screen sizes, “sparse” and “loaded”,
- select which to load initially based on the viewing device, and
- allow the user to easily change to the other
(e.g. I often want to use the “loaded” design, the full web site, when on my iPhone or Android, just because I want all that info and the peripheral affordances offered on big screens).

Even I, who hate responsive design, am being pushed by current trends to using it. All the people I hire to do design any more uses it by reflex. And it’s really hard to make something decent on both sized screens. So I’m using it under protest, hoping it will go away soon.

(This blog started as a FB post, I’m putting it here for my other friends to see).

Why Adopting Agile Won’t Magically Reduce Your IT Budget

Agile Connection -

Of course, all companies would like to reduce their budgets. But cutting back in the IT department can have unintended consequences. This article looks at two of the more well-adopted cost-cutting approaches, the software factory and distributed teams, and goes into how they can help and hurt your company.


Subscribe to Torak - Agile Scrum Kanban Coaching Training Phoenix AZ aggregator