Feed aggregator

The Agile Checklist Manifesto

VersionOne Agile Management Blog -

Airline pilots use a checklist to clear their planes for takeoff.  In an experiment Dr. Pronovost, a critical care specialist at John Hopkins, used the checklist strategy to attack just one common problem in the I.C.U., infections in patients with central intravenous lines. Dr. Atul Gawande is the author of The Checklist Manifesto: How to Get Things Right. He is a MacArthur Fellow, a general surgeon at the Brigham and Women’s Hospital in Boston, a staff writer for The New Yorker, and an assistant professor at Harvard Medical School and the Harvard School of Public Health. In his review of The Checklist Manifesto book, famous writer Malcolm Gladwell states “Although the book is written by a surgeon …. it is really relevant to how professionals deal with the increasing complexity of their responsibilities…It has been years since I read a book so powerful and so thought-provoking.”  No wonder, the book is a New York Times, Wall Street Journal, USA Today, Entertainment Weekly, Washington Post, Los Angeles Times, Boston Globe, and San Francisco Chronicle Bestseller. The important point Dr. Gawande is making is that the complexities of professional work in the 21st century may be best handled by the simplest solution of checklists. The counterpoint usually comes in two flavors: ·         My job is too complicated (or too important) to reduce to checklists – an argument by cynical surgeons that Dr. Gawande ran into.  This argument is easily refuted with the success Dr. Gawande’s checklists have enjoyed in hospitals. ·         Checklists reduce my flexibility, creativity, spontaneity; or they are too bureaucratic.  The argument can be refuted by recognizing that any tool can be misused.  Rigidly enforced, top-down, heavy-handed, compliance-oriented, slavishly-followed checklists will indeed create problems; but highly customizable checklists developed by professionals and teams of professionals doing the work, supported by appropriate tool, and used by those empowered professionals can be very helpful.  These kinds of smart checklists will take the drudgery and errors out of complex work, and thus, freeing up time for creative work. As incisively reported by Robin Marantz Henig in her New York Times article, checklists work really well because ”In an age of unremitting technological complexity, where the most basic steps are too easy to overlook and where overlooking even one step can have irremediable consequences, something as primitive as writing down a to-do list to “get the stupid stuff right” can make a profound difference.” I have been using checklists in my own agile coaching, training, consulting engagements: travel checklist, logistics checklist, preparatory homework checklist, follow-up checklist, etc.   Overlooking one critical step has proved damaging and harmful (at least to me and sometimes to my clients), and my checklists have been the saviors.  They unburden me and my clients from having to remember stuff or not miss the obvious in the frenzy of many things swirling around us.  Life becomes more relaxed, and error rate and goof-ups go down dramatically. Most of us working in agile development or agile management are neither airline pilots nor surgeons, but we deal with complex projects involving many people and teams, and lots of rapidly changing details where the devil lurks.  Simple, customizable checklists, in my experience, are highly effective in slaying the complexity devil. I will now present several examples of checklists applicable at the level of individual agile team members as well as agile teams.  Each checklist contains a number of items (such as tasks, tests, steps, options, questions) with a role assigned to each item (task, test, and step).  A checklist may or may not imply any order for items in it, or it may include a built-in workflow.    I recommend you review, customize and try the checklists presented in this blog, and then relentlessly inspect and adapt them, i.e., make them work for you with fine tuning and revisions based on your own experience.   If a task in a checklist is not applicable in your specific situation, you are free not to do that task with a reason that you can explain to yourself and to your team members.   If a specific task quite often need not be done or is missing in a checklist, the checklist itself should be revised (inspect and adapt) by deleting the unneeded or adding the missing task in the checklist.  You will be a lot more effective that way instead of  trying to recall from your memory without any checklist all the tasks you may have to do (and then missing at least some, or a lot, or them).

User Story Checklist

Table 1 shows a checklist of typical tasks and tests in a user story.  This should help a cross-functional agile team to pay attention to all these tasks and tests and not miss any work for the story in order to complete it and get it accepted by the product owner.   If a story requires multiple design and code development tasks and multiple acceptance tests, more tasks and tests can be added to that specific story than shown in Table 1.  Some tasks in Table 1 are optional, and may not be needed for a specific story.

Table 1: Tasks and tests in User Story Checklist

Defect Checklist

Defects found, especially outside a sprint such as in production, can be logged with the following checklist of tasks and tests.

  1. Task: Log the defect with steps to reproduce the defect: QA tester
  2. Task: Analyze and debug the defect: Developer
  3. Task: Fix the defect: Developer
  4. Task: Specify the test to verify the defect: QA tester
  5. Test: Execute the test to verify it: QA tester
  6. Task: Close the defect which has been verified as fixed: QA tester

Epic Breakdown Checklist

This checklist is based on the work done by Richard Lawrence where he recommends 9 patterns that you should try to use to break down an epic (a large story or feature) into smaller user stories.  I have listed these 9 patterns as options below. A customized checklist augmented with a brief example for each pattern suitable for your organization will be very handy and effective when it comes to breaking down epics into stories.

  • Option 1: Workflow Steps
  • Option 2: Business Rule Variations
  • Option 3: Major Effort
  • Option 4: Simple/Complex
  • Option 5: Variations in Data
  • Option 6: Data Entry Methods
  • Option 7: Defer Performance
  • Option 8: Operations (e.g., CRUD)
  • Option 9: Break Out a Spike

Sprint Planning Readiness Checklist

This checklist consists of a list of preparatory tasks that should be completed before starting a Sprint Planning Workshop or Meeting.  These tasks should be completed ideally one timebox ahead, i.e., in parallel with the previous sprint execution.  Completion of these preparatory tasks will help ensure a highly effective and productive sprint planning workshop, which is a time-boxed event (1/2 day for a two-week sprint or one day for a four-week sprint).

  1. Task: Define the Agile team, its members and their roles/responsibilities: ScrumMaster
  2. Task: Draft the key objectives for the upcoming Sprint: Product Owner
  3. Task: Define and create the project hierarchy in Agile Project management (APM) tool, and make sure the members of the Agile team have the right role assigned on the project:  ScrumMaster working with APM tool administrator
  4. Task: Create the Sprint backlog in APM tool: Product Owner working with Business analysts: Epics, stories (preferably satisfying the INVEST criteria, Defects, Spikes, Maintenance work, porting work, certification work, Regression testing, System testing, Performance testing, etc.
  5. Task: Explain and clarify the sprint backlog to team members for the upcoming sprint by conducting one or more sessions one timebox ahead, i.e., sprint work done in a pipeline mode (see details in my blog on Is Your Sprint Pipeline Running Well?): Product Owner.
  6. Task:  Calculate agile capacity for the team and each team member for the upcoming sprint (for capacity-based sprint planning – see details in my blog on agile capacity calculation): ScrumMaster working with each team member
  7. Task: Prepare the preliminary rank order of backlog items based on business value (Optional): Product Owner
  8. Task: Make sure all IT environments are in place: ScrumMaster working with IT staff: Development, QA, build machine, continuous integration server, software licenses, test data, any special hardware needed
  9. Task: Review the Sprint Ready checklist (see below) and take necessary actions so the Agile team will be 100% ready to start the sprint as soon as the Sprint Planning Workshop is over: ScrumMaster.
  10. Task: Complete all logistical arrangements for Sprint Planning Workshop (venue decided, attendees identified and invited, workshop material arranged, food ordered, etc.): ScrumMaster
 Sprint Planning Workshop Checklist

The checklist shown in Table 2 consists of a number of tasks (Tasks T1 through T14) to be completed during a Sprint Planning Workshop.  Rough time estimate for each task is indicated for a typical three-week sprint planning being done for the first time.  With process maturity, experience and well-jelled teams, this planning time should come down to ½ day for two-week sprint planning to 1-day for four-week sprint planning.

Table 2: Sprint Planning Workshop Checklist


Sprint Ready Checklist

This checklist consists of a set of tasks that must be completed before a sprint should start and can run smoothly.  If there is major incompletion of any of these tasks, it would be premature and risky to start a sprint, as it will experience obstacles, hick-ups, delays and impediments.

  1. Task: Sprint objectives are well defined: Product Owner
  2. Task: Full inventory of all work items is available, and all tasks and tests in stories of the sprint backlog are properly defined and  have proper estimates: Product Owner, ScrumMaster
  3. Task: Acceptance tests for each User story are well defined: Product Owner, QA tester
  4. Task: All Agile team members are identified, their roles defined and necessary training completed or plans made: ScrumMaster
  5. Task: Individual and total capacities and Individual and total estimated efforts match (for capacity-based planning): ScrumMaster
  6. Task: Various standards (coding, testing, documentation, build, user interface, compliance, etc.) for your project are defined and easily available: ScrumMaster, Team Leads
  7. Task: All IT environments, infrastructure and test sets required for the Sprint are available: ScrumMaster and IT staff
  8. Task: Work is distributed evenly across all members of Agile team (load balancing done): ScrumMaster
  9. Task: All stories in the Sprint are linearly rank ordered: Product Owner with Team
  10. Task: Sprint Done Checklist is well defined: Product Owner with Team
  11. Task: Any remaining small tasks that must be completed to reach 100% Ready state are documented (and are not show-stoppers): ScrumMaster

Daily Scrum Checklist

This checklist consists of a set of tasks for each individual member and also for ScrumMaster.  See specific details in my blog on Daily Scrum.

  1. Task: Ensure that the Daily Scrum room venue and timing is the same for every day in a sprint: ScrumMaster
  2. Task: Invite each member of the Agile team for Daily Scrum on a standing basis for every day throughout the sprint duration: ScrumMaster
  3. Task:  Prepare for the Daily Scrum meeting ahead of the actual meeting: Each team member
    1. Report on the status of yesterday’s tasks against the plan for yesterday
    2. Present the plan for today’s tasks
    3. Present what do I need from any other team members to do my work
    4. Present any impediments on the horizon that could block my work
  4. Task: Present key information radiators from APM tool, such as burn-down and burn-up charts, Cumulative Flow diagram, Impediments being worked on: ScrumMaster
  5. Task: Capture any risks, issues, and decisions coming out of Daily Scrum: ScrumMaster

Sprint Done Checklist

This checklist consists of a set of tasks that must be completed before a sprint can be declared successfully “Done”.  This list ensures unambiguous completion of a sprint.    

  1. Task: Acceptance testing completed: QA testers
  2. Task: Defect fixing work completed: Developers
  3. Task: Fixed defects are verified and closed by QA members of the agile team: QA testers
  4. Task: The list of defects to be pushed out to the next sprint is finalized: Product Owner, ScrumMaster, Team
  5. Task: All technical documentation is completed: Technical leads
  6. Task: All user documentation is completed and is ready to be released to sprint users: Tech writer
  7. Task: Sprint release can be delivered to interested customers and users ready to receive it: ScrumMaster
  8. Task: All data in APM tool is up-to-date and consistent with the completion (Done) state of this sprint: ScrumMaster and Team
  9. Task: Sprint delivery has met the Sprint objectives: Product Owner
  10. Task: Sprint release is accepted by the Product Owner: Product Owner

Sprint Retrospective Checklist

This checklist consists of a set of tasks that must be completed during Sprint Retrospective session (typically a 1 to 2-hour timebox) so that the team can develop a SMART action plan that it can act on during the next sprint to improve its own agile process in a specific way.  See specific details in my Sprint retrospective blog.

  1. Task: Determine up to 3 top things that worked really well, and the team wants to continue: Team
  2. Task: Determine up to 3 top things that were most problematic, and the team wants to discontinue or change: Team
  3. Task: Determine up to top up to 3 impediments and their root causes: ScrumMaster
  4. Task: Capture and present key statistics, such as initial capacity of the team, planned vs. actual velocity, scope change.  Most of these are reports generated by APM tool: ScrumMaster
  5. Task: Develop 3 to 5 specific action items as part of the Specific, Measurable, Achievable, Realistic, Time-bound (SMART) action plan to improve the agile process: Team
  6. Task: Convert the SMART action items into Stories in APM tool, and assign them to the next sprint: ScrumMaster

Need more information?

By no means, this is neither a complete set of all agile checklists nor I am suggesting that all agile development work can or should be captured into checklists.     However, you may think of several recurring activities with some degree of complexity as good candidates for checklists.  Some examples:  Daily Builds, Compliance and Certification Testing, Customer Trial and Evaluation Testing, Customer Acceptance Testing, Release Packaging, Delivery and Deployment, Customer Support Calls, etc.   Even the well-known INVEST criteria can be thought of as a checklist to make sure that stories in a backlog are Independent, Negotiable, Valuable, Estimable and Testable; and the SMART tasks within each story as another checklist for tasks that are Specific, Measurable, Achievable, Relevant and Time-Boxed.

Agile checklists can also be used as an effective mechanism to plan, coordinate, align and synchronize work across a larger number of agile teams on a large-scale agile project, such as a program or a SAFeTM release train of 5 to 10 agile teams working in synchronization on the same cadence, and a set of programs constituting an agile portfolio of several hundred people.   Dean Leffingwell’s book on Agile Software Requirements presents a very comprehensive Release Planning Readiness Checklist in Appendix C.  A Wikipedia section on Non-Functional Requirements (NFRs) gives a fairly comprehensive list of NFRs to consider.  You may use that list as a checklist to minimize the probability of overlooking or missing one or more NFRs while preparing and grooming your product backlog. The benefits of agile checklists increase even more when you want a large number of team members on multiple teams of a large-scale agile project to do their coordinated work in a consistent, standard way, and to avoid unnecessary variations among different teams and their members when there is no reason of or benefit from those variations.  Thus is the case because larger scale projects create additional complexity due to the need for aligning and synchronizing multiple teams in a program and managing a number of programs into a cohesive portfolio. An APM tool like VersionOne can make it very easy to templatize these checklists so all items within each checklist can be modeled as tasks and tests in a template; then those tasks and tests can be completed in a consistency way without errors across a large number of people and agile teams.  A team can have its own set of checklist templates, and projects and programs can have their own checklist templates, in addition to a standard set of checklist templates that are common for all members, teams, projects and programs in an enterprise.  If you are not yet using an APM tool that supports templates, don’t let that stop you from using agile checklists.  Try using Excel files on SharePoint or spreadsheet docs on Google Drive for creating and maintaining your checklists.  That will get you going quickly.

For additional information on agile checklists, you may find VersionOne agile checklist white paper very informative and imminently actionable.

Have you tried checklists on your agile project?  What is your experience?
Are you interested in experimenting with your own set of checklists?
I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).

Leadership Dashboards: Post 2

Scrum Log Jeff Sutherland -

This is the second post in a series about creating effective leadership dashboards.  You can catch the first post in the series on the goals of an effective agile dashboard here.
This post focuses on how to organize the creation of a great dashboard.  How the dashboard is created is often overlooked in favor of diving directly into what metrics to include, and the look and feel of a complete dashboard; but being deliberate in the process can dramatically improve the finished product and prevent the alarmingly frequent incidents of total failure.  For example, a client I am currently supporting in dashboard creation had previously worked with a large accounting firm to create an executive dashboard for their development group…six months and hundreds of thousands of dollars later, the project was cancelled without the leaders ever having seen a single working metric!
There are three main pillars for how to create a successful leadership dashboard:
  •      Use Scrum to develop the dashboard
  •      Develop a prioritized backlog of metrics and deliver incrementally
  •      Leverage an “interactive” interface and drill down hierarchy

Use ScrumIt should come as no surprise that I recommend using a Scrum team to develop and deploy the leadership dashboard. (After all, we use it for everything here at Scrum Inc.)  But interestingly enough, when most companies embark on developing a dashboard, they tend to treat it like an internal side project and not give it the full focus, attention and agile discipline that they apply to their customer-facing work.  With unclear roles and objectives, and competing with a dozen other projects for employee attention these informal efforts often go nowhere. 
If you are serious about developing a useful dashboard, designate a dedicated and cross-functional team to build it.  Maintain the discipline of working off a backlog of metrics to deploy and identify a product owner to incorporate user feedback. Leverage the structure provided by a regular sprint cadence with demo and retrospective meetings.  It may feel like a lot of overhead, but you will be glad you made the investment when enjoying your completed dashboard.
Deliver IncrementallyWhat caused the failed dashboard effort mentioned above, and countless others before it, was the attempt to deliver a working dashboard in a single “big bang.”  The hallmarks of this approach are to “mock up” the look and feel of all of the metrics in a dashboard, get buy in from leadership on that design, then build the dashboard.  Unfortunately, this waterfall approach is no more effective for dashboard creation than it is for software development, and for exactly the same reasons: 1) leadership doesn’t really know what they need to see to make effective decisions until they see it, leading to a “moving target” that can consume years of back and forth mock-up revision; 2) too often, teams agree on a mock-up only to discover that it is impossible to pull the data required to make it a reality; and 3) company data and systems are complex and interdependent…small changes to one element of the dashboard have ripple effects throughout the tool, making after the fact changes a nightmare.
Fortunately, dashboards lend themselves extremely well to iterative and incremental delivery. Each combination of metric and business unit within the company is a useful feature that can be delivered and refined independent of the other metrics.  Integration, summary views and second-order metrics can then be layered on.  A savvy product owner in dialogue with the dashboard’s end users can easily prioritize which metrics and which business units are of greatest concern and prioritize the backlog of metrics appropriately to deliver the greatest value as early as possible.  Ensuring that there is an easy way for users to provide feedback within the first iteration of the dashboard makes this process even more straightforward.
The biggest challenge here is to set appropriate expectations with leaders in advance about what incremental development looks like and get a commitment to providing feedback.  They might be resistant at first to a partially completed product or the effort of feedback, but it is imperative that they provide actionable guidance to produce an effective dashboard.  “It isn’t good enough yet” is a common response, but not sufficiently engaged and actionable to help the team. 
In the past, I have positioned the value proposition for incremental delivery as, “The initial version will be rough, and I can almost guarantee that you won’t like it; however: you will have something in your hands within x days, it will be REAL data that will improve your visibility over what you have now, and we will implement any actionable feedback you have over the subsequent iterations to make the dashboard exactly what you want it to be.”  This usually works, though it is worth getting agreement in writing for the inevitable retrenchment later.
Leverage an Interactive ToolThe default expectation in the business world is that a dashboard is a single page or PowerPoint file that contains summary metrics and can be transported around for easy reference.  While this is fine in practice, the advent of cloud computing and ubiquity of mobile devices have opened up significant new possibilities for interactive metrics reporting.  Here again, a little up front expectation setting is essential to leveraging this potential.
A single flat dashboard can only show top-level metrics and tends to get very cluttered as more information is added.  By contrast, an interactive data visualization tool like Tableau or Domo can have a clean and simple top-level design, but allow the decision-maker to click-down into disaggregated views as needed (stay tuned for more detail on tools in a future post).  It provides more data, but gives the user control over how much detail to show.  The data can be updated at different cadences or even in real time, rather than a single monthly update to a PowerPoint slide. Finally, with dashboards fed to mobile apps, the information is even more readily available than the printed dashboard page.
That said, remember that the dashboard’s ultimate purpose is to help leaders make decisions, so particularly in the early iterations it may be helpful to build a dashboard that looks familiar and comfortable to leadership.  Having built credibility in the process and team, you can then flex your interactive muscles and deliver value-adding capabilities.
In the next post, we will cover what information leaders typically want updates on a regular basis, and how to achieve those objective with compelling agile metrics. If you want a sneak peek at some of these metrics, they are covered in our online course on The Scrum Leader’s Dashboard.
Alex Brown is Scrum Inc’s Chief Product Owner and Chief Operating Officer.  He set up the company’s internal metrics dashboard to automatically consolidate and share agile metrics and support better decision-making.  He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.

What’s So Special About Agile?

VersionOne Agile Management Blog -

Admit it.  You enjoy telling people that you’re an Agile “practitioner”, “coach”, or “evangelist”.

It’s OK – I do too.

I also enjoy reading a well-researched article in, say, the Harvard Business Review or the Wall Street Journal that validates what we do every day in the Lean-Agile community.  It shows that they want what we got (and sometimes, vice versa).

But I recently happened across the April 2011 issue of Real Simple magazine, the riveting theme of which was “Spring Cleaning”.  My curiosity as to how that subject could possibly warrant an entire issue led me to thumb through the pages until I came across an article entitled “This is Your Brain on Procrastination”, written by Amy Spencer.

The article presented the following list of things to do in order to get important things done around the house:

  • Do the worst thing first (you won’t have the energy to do it later)
  • Start your day over at 2:00 PM (assess and adjust regularly)
  • Make the job smaller (and do it just “good enough”)
  • Create an audience (make yourself accountable)
  • Race the clock (see how working in short, timed bursts affects your productivity)
  • Don’t interrupt yourself (or let anyone else do so)
  • Plan an unprocrastination day (prioritize and then immediately DO)

Sound familiar?  I thought so, too.

Yes, three years ago, guidance for which people still pay good money to be Agile-certified was published in an article on getting ahead on household To-Dos.  That tells me that maybe Agile isn’t so special anymore.

I think that’s actually a good thing.

Why? Because I noticed a long time ago that most of us tend to use one system of thinking at home, and another when we’re at work.  It’s almost as if we swap brains somewhere between the front door and the driveway.

For example, Home Brain says, “I have only so much money and so much time, so I’m going to have to accept the fact that I can’t have both a new refrigerator AND a new fence.”

Work Brain says, “Based on our best information, I know we can only really do the fridge. Tell you what: I’ll throw the fence in as a ‘stretch goal’.”  (Home Brain’s too smart for that.  He knows what stretch goals turn into.)

My efforts over the last several years, to a great extent, have been focused on simply getting people to take their Home Brains to work with them.  The addition, now, of even informal Agile thinking to Home Brain’s innate clarity and common sense will make it that much more valuable at work.

So what if Agile’s mysteries are being divulged to the uninitiated as they stand in the supermarket checkout line?   If value-oriented and throughput-focused thinking can permeate such mundane areas of our lives as decluttering a closet, then the the way we are trying to shape how we think at work will become more similar to how we think at home.

That should make bringing an Agile mindset into the workplace more natural.  I’m OK with that, even if it means Agile loses some of its status in the process.

How To Thrive As an Agile Tech Writer

Rally Software - Agile Blog -

Ah, tech writers. We do more than tell the user how something works -- we also explain the caveats and intricacies behind why a feature or enhancement functions the way it was designed. It’s a tech writer’s job to learn and communicate the value of any software we deliver to customers.

Since our Rally Help site contains over 1,000 pages of content, it’s imperative that we interface with other teams on a predictable cadence so we know what needs to be updated or refined. Our content also relies on the feedback we receive and our customers’ expectations that they have the online help they need at their fingertips.

Over the past year our User Learning team has worked hard to become a highly productive, relevant, and visible team that is responsive to customer needs and expectations. Here are a few examples of challenges we've met and solutions we’ve provided.

Challenge: Our customers need more than written help

Solution: Give them what they need!

Our team creates written content, videos, and tutorials to cater to many different learning styles. Last year, we decided to create a new type of content: GIFs. GIFS are a dynamic way to show what it looks like to use a new enhancement or navigate to a specific place.

When you think about it, who has time to read through extensive documentation? Any time we can create a GIF that shows you how to do something in less than 10 seconds, we do it!

For example, here’s a GIF that shows you how to mark a card on a board as ready to pull or blocked:

Great end-user documentation is much more than mandatory written instructions. Breaking content into easily consumable bites and leveraging technology like GIFs and video is critical. Whenever our customers need to gain an understanding of new functionality, our team works to create easily consumable content.

Challenge: Our team is the last to know about a new feature or enhancement

Solution: Collaborate early and often

When a feature or enhancement is released, the work of tech writers is often viewed as an afterthought. After planning, the product owner should be able to provide the tech writer with a timeline and enablement information for a new feature or enhancement.

So our team reaches out to product owners for details on business value, timeline for release, and user enablement on at least a weekly basis. We also get invaluable input from our user experience team, developers, and testers concerning issues that users may encounter with a new feature or enhancement.

We attend weekly feature status meetings and occasionally sit in on another team’s standup if a large feature is coming out soon and frequent changes might affect our documentation or videos. We also lead weekly meetings for other teams to learn about upcoming releases and review recently updated documentation.

This visibility with other teams has greatly increased our preparedness when documenting new features. Plus, we get the added bonus of seeing how the feature evolves week-by-week before it’s released to our customers.

Challenge: Feedback is second-hand, and mostly internal

Solution: Give customers the opportunity to provide direct feedback

While our team has received great feedback about our Help site from people who work here at Rally, we realized we were missing something: direct feedback from our customers.

That’s why we implemented a feedback form on all pages of our Help site. We receive daily feedback and we read each and every message we receive. Yes, reading through all of these messages takes time, but it has opened our eyes to who is using our content and how they use it, as well as helped us identify gaps in our content.

This direct customer feedback has been critical to improving our content. Our users have contacted us about everything from broken links to clarification about the functionality of a burndown chart.

Over the past year, our team has learned how to engage both the internal and end-user consumers of our help content. Now, instead of being an afterthought, the content we create is an integral part of creating value for other Rally teams and our customers.

Erika Edwards

ActionCLUB - Business Mastery Program

Events - Eventbrite -

Thursday, April 17, 2014 from 3:00 PM to 5:00 PM (PDT)

Dobson's at Dobson Ranch Golf Course
2155 S. Dobson Road
Mesa, AZ 85202

Hosted By:
Dimitri Ponomareff, ActionCOACH Business Coaching

Dimitri is a Coach. Whether it's a sports team, software products, business owners or executives, Dimitri has that ability to relate and energize people. He is consistently recognized as a very passionate and successful change agent, with a great capacity to motivate and mobilize teams on the path of continuous improvements. He is a master facilitator, as well as a very exciting speaker with overwhelming positive feedback about his ability to engage an audience.

As a certified Coach, Project Manager and Facilitator of "The 7 Habits of Highly Effective People", he brings a full spectrum of building systems that are well orchestrated by people who understand where to focus their work to generate the most value.

His experience as a Coach includes the following organizations Charles Schwab, American Express, Mayo Clinic, LifeLock, Bank of America, Choice Hotels International, JDA Software Group, Wolters Kluwer, Apriva Mobile, Fiserv and Phoenix Children's Hospital.

Register for this event now at:

Event Details:

The ActionCLUB Business Mastery Program is a 12 session - 26 week group business coaching program for business owners. It’s like getting a semester of business education, but with proven real-world examples. We focus on helping you with your business so you can implement strategies immediately as you move through the program.

What you will learn during the program...

At ActionCOACH, we believe in the principle, give a person a fish, they will eat for a day; teach a person to fish, they will eat for a lifetime. Our objective is to “teach you to fish” so you can apply the strategies in your current business plus any business you may own in the future. You’ll be given all the tools so you can see real results as you go along. Here’s what you’ll learn through the sessions...

Session 1 - Introduction and Business Profitability Session
Before you can start you will need to understand exactly where you are in your business, what the course is about and how it can benefit you. Most clients get excited at this point because they realize there is a way to achieve what they want and more. You will also be introduced to your Business Planning Toolkit. This will be your companion from this point forward in both your life and your business. It includes a comprehensive business audit and a system for planning.

Session 2 - Focus
In this first group session you will set your goals, company’s vision and mission and you’ll learn how to build a great business from the base up. You’ll also learn about the importance of having a good plan and using your time effectively!

Session 3 - Cash
This session will teach you about the importance of understanding your financials. This is the key to knowing where your cash comes from and goes to...and how to keep some of it! You’ll learn how to improve your understanding of your financial statements, your cashflow cycle and how to look beyond break-even!

Session 4 - Leverage
You will learn about the principles of leverage. You’ll focus in on the fastest ways to increase your business success across all areas of your business using ActionCOACH’s 5 Ways Mastery and the importance of measuring and testing...everything!!

Session 5 - Lead Generation
You will extract your uniqueness, that which sets you apart from your competitors, and learn how to use it to get more of the customers you want. You will also learn about how to put together great advertising to make sure your customer acquisition cost is low and your lifetime value is high!

Session 6 - Conversion
You’ll learn about the different types of salespeople and the difference between old selling and new. You will learn to understand the question funnel and how to handle objections.

Session 7 - Client Fulfillment
This session is about client fulfillment. Now you have done all the hard work to get them, it’s critical to keep them. You will learn about developing customer loyalty so your customers keep coming back… time after time.

Session 8 - Systems
Learn about systematizing your business. Learn how to create systems that run your business to produce massive results. Learn how you can work ON your business rather than IN it.

Session 9 - Team
This session is all about building the dream team you’ve always wanted. Learn how to become a great leader to inspire them each and every day. Learn how to recruit great people and lead them to a business that works without you.

Session 10 - Leverage, The Board Game.
Join other business owners and have some fun and recognize how the 5 Ways system comes together and can be integrated into your business on a day to day basis. This is not just for fun - this an excellent learning tool and networking opportunity.

Session 11 - GrowthCLUB - 90 Day planning
Join all our clients in our GrowthCLUB 90 Day Planning session. This is where you get to write your own business plan for the next period.

Session 12 - 1 on 1 Business Coaching Session
You and your Coach review and plan created during the program your next steps.


Each session is focused on you learning what you can do today to get your business moving…

The most practical, dynamic, and profitable business, sales and marketing program you’ll ever invest in, and here’s why …

It’s not just finding out ‘what’ you need to do ... you will leave this program knowing ‘how’ to do what you need to do to get ahead. And not only that ... you will have done most of it in the program ... Invest in sessions with ActionCOACH, developing and adapting some of the three hundred and twenty eight business building strategies, to use specifically in YOUR business, to boost YOUR profits and free up YOUR time ... right now ... You’ll find out how to get working smater, so that you WORK LESS while taking home more money ...

Is Your Sprint Pipeline Running Well?

VersionOne Agile Management Blog -

Most agile teams, when starting out new on their agile transformation road, conduct all sprint related activities in the same timebox, i.e., sprint planning, sprint execution, sprint review and sprint retrospective.  This is illustrated in Figure 1, where each sprint (from Sprint 0 through N+1, represented by each row) is mapped onto a single sprint timebox (Timebox 0 through N+1, represented by each column), and successive sprints are executed in successive timeboxes in a sequential order (Sprint 0 in Timebox 0, Sprint 1 in Timebox 1, and so on).

 Figure 1: Sequential execution of sprints

For example, all implementation tasks for Sprint 2 (analysis, design, code development and unit testing, acceptance test case development and acceptance testing, defect fixing – done concurrently (not as a mini-waterfall) by a self-organized, cross-functional team — are completed in Timebox 2.  Sprint 2 planning is completed (before Sprint 2 starts) in approximately 4 hours for a two-week sprint (or 8 hours for a four-week sprint); and sprint review and retrospectives are completed in approximately 1 hour each for a two-week sprint (or about 2 hours each for a four-week sprint).

Each light pink vertical thin box separator between two successive sprint timeboxes represents a small timebox to complete all these ceremonies, i.e., sprint review and retrospective for the previous sprint as well as sprint planning for the next sprint.   Thus all these tasks for successive sprints are carried out in a sequence of successive timeboxes.  This is a simple and straightforward model where work goes in each timebox sequentially, sprint by sprint, without any overlap.

What are the advantages of and the challenges for the simple model of sequential sprint execution shown in Figure 1?

Advantages of the sequential sprint execution model:

1AS.    Simple to teach, understand and learn – and hence covered by all agile text books, training courses, and certification programs.

2AS.    Conceptually simple to execute — but fraught with challenges as explained below.

Challenges for the sequential sprint execution model:

1CS.     Analysis issues may block the team and reduce throughput: Analysis of backlog items (or stories, as they are often called) must involve intense conversations among the product owner and team members, and confirmation of each story by defining its acceptance criteria.  Stories can be properly understood only through conversation and confirmation parts of the story metaphor of card, conversations, and confirmation.   The product owner should answer the questions and clarify the issues raised by the team members before design and code development work can start.     This goal – clarifying all stories to reach a collective, common, shared understanding – may become very challenging if all stories are analyzed during the same timebox in which they are scheduled for design, code development, testing, defect fixing and delivery.   This is so because the product owner may not know all the answers to team members’ questions without consulting users, customers and stakeholders, and performing necessary market and customer research and analysis.  This entire analysis effort is often difficult to compress in the same timebox when design-development-testing-defect fixing work is also going on concurrently because the actions of many actors responsible for providing answers to the analysis questions may be beyond the control of the product owner (for example, some stakeholders or customers may not be available to provide specific clarifications within the timebox time constraints).   The net effect of this challenge is often reduced team velocity (throughput) as the team is still waiting for stories to be clarified while sprint execution is going on, and team members may be even blocked waiting for clarification.  Finally the sprint timebox may be over before some planned stories could be completed by the team members and accepted by the product owner.

2CS.     Sprint planning may be less effective and efficient: Without clear and shared understanding of each story by all team members and the product owner, the team will find it difficult to estimate the work effort and complete all sprint planning tasks in the allocated time for sprint planning (approx. 4 hours for two-week sprints and 8 hours for four-week sprints).   Needless to say poorly planned sprints contribute to poor (ineffective and inefficient) sprint execution and reduced throughput.

A better model to overcome the challenges of the sequential sprint model is to execute sprints in a pipeline fashion as illustrated in Figure 2, where the Analysis task is performed one timebox ahead of the Design-Code-Test timebox for each sprint.  For example, development and analysis of Sprint 2 backlog is performed during Timebox 1 (one timebox ahead of Timebox 2), while the actual design, code development and unit testing, acceptance test cases development and testing, regression testing and defect fixing tasks for Sprint 2 are performed in Timebox 2.  This same pattern repeats for each sprint, i.e., the work for each sprint proceeds in a pipeline manner, and as a consequence, the work for each sprint is spread over two consecutive timeboxes in an overlapping manner with the next sprint.

Figure 2: Sprint pipeline

 What are the advantages of and challenges for the pipeline model of sprint execution shown in Figure 2?

Advantages of the pipelined sprint execution model: 

1AP.   Analysis work proceeds smoothly without blocking the team: As analysis work is carried out one timebox ahead of design-development-testing-defect fixing work for each sprint, the stories are substantially clearer by the time the team enters the Sprint Planning Workshop for each sprint.  Note that the product owner has a full sprint timebox (typically 2 to 4 weeks) to consult with the necessary users, customers and stakeholders in order to answer team members’ questions on stories.  And while this clarification of stories for the next sprint is going on, the team members are not held up or blocked as they are implementing the stories for the current sprint.   Effort estimation and other sprint planning work proceeds more smoothly and can be more easily completed during the Sprint Planning Workshop.

2AP.   Team experiences higher throughput with well understood stories and well-planned sprint: Note that although each sprint work is spread over two timeboxes (as shown by the blue oval in Figure 2), the throughput is not adversely impacted because the team is still delivering working software at the end of each timebox.   In fact, as sprint planning effectiveness and efficiency goes up and stories become clearer, there is a lot less uncertainty about stories as the sprint starts, which reduces impediments, improves team morale and dynamics, and improves team’s throughput compared to sequential execution of sprints.

Challenges for the pipelined sprint execution model: 

1CP.   In each timebox, the team needs to work on two sprints: Although most of the time the team is focused on design-code development-testing-defect fixing work for the current sprint, some of its time must be set aside to analyze the backlog items prepared by the product owner for the next sprint.  This is indicated by the red oval in Figure 2, where the team is spending most of its effort on design-code development-testing-defect fixing for Sprint 2 in Timebox 2, while at the same time spending some effort in analyzing the stories for Sprint 3.   Some teams — especially when they are new to agile — may find working on two sprints in the same timebox challenging.

2CP.   Small risk of doing wasteful work: There may be a small risk of analyzing few stories one timebox ahead of their actual implementation that may end up not being part of the next sprint commitment due to change in priorities as the next sprint planning is completed.   Some people may even object that doing analysis one timebox ahead of the actual implementation could be somewhat wasteful, and it goes against the “just-in-time” agile work philosophy.

I will now explain how to deal with both of these challenges, 1CP and 2CP.

Solution to the challenge of working on two sprints in the same timebox (1CP): The ScrumMaster for the team can help manage work on both sprints in the same timebox (i.e., design-development-testing-defect fixing work for the current sprint as well as analysis of backlog items for the next sprint) by establishing and following a Sprint Cadence Calendar as illustrated in Figure 3.

 Figure 3: Two-Week Sprint Cadence Calendar

The two-week Sprint Cadence Calendar has 10 work days, with workday starting at 8:00 AM (0800 hours) and ending at 5:00 PM (1700 hours). The team should allocate about 30 minutes for preparation for the Daily Scrum (DS) meeting and actual attendance by each team member.  These DS meetings should be held every day of the sprint at the same time and place.   In Figure 3, these DS meetings (preparation and actual meeting) are shown as starting at 9:00 AM and ending around 9:30 AM every day.  If you are interested in understanding and implementing highly effective and efficient Daily Scrums, please take a look at my Making-daily-scrum-meetings-really-effective-efficient blog on the subject.  The other ceremonies (Sprint Planning, Sprint Review, and Sprint Retrospective) are also illustrated in Figure 3. If you are interested in understanding and implementing really effective Sprint Retrospectives, please take a look at my Making-sprint-retrospectives-really-effective blog on the subject.

As shown in Figure 3, I recommend that the analysis of backlog items for the next sprint should be scheduled on a regular cadence, where a two-hour meeting is held on every Wednesday (3 PM to 5 PM), as an example.  In these two meetings in a two-week sprint (a total of 4 hours or approximately 5% of the time in the two-week timebox), the product owner and the entire team converse about each story and also confirm each story with its acceptance criteria.  If the product owner cannot answer some questions in the meetings, he/she has adequate time left in the two-week sprint timebox to get those questions answered in consultation with users, customers and stakeholders, without blocking any team member.

I also recommend that the product owner grooms the product backlog and prepares a draft of backlog items for the next sprint on a regular cadence, shown on every Tuesday (3 PM to 5 PM) in Figure 3.  The cadence or pattern for sprint planning, sprint review, sprint retrospective, analysis for the next sprint, and product backlog grooming (shown in Figure 3) is for illustrative purposes only.  Your team should discuss and experiment various sprint cadence options to find the cadence that most suits your needs and choose the cadence that best works for you.  For example, a team may hold Sprint Review and Retrospective for the previous Sprint on Week-1 Monday morning (9 AM to Noon)  followed by Sprint Planning Workshop for the current sprint from 1 PM to 5 PM.  Another team may start the Timebox on a Wednesday (instead of Monday), and two weeks later end it on a Tuesday (instead of Friday), i.e., stagger the start and end of the timebox shown in Figure 3 by two work days to avoid Sprint Planning, Sprint Review and Sprint Retrospective falling adjacent to a weekend day (and tempting some team members to miss them due to their long weekend vacation!).

Regular cadence for all the activities mentioned above minimizes coordination, scheduling and transaction costs; increases predictability through a disciplined schedule published ahead of time for several release cycles (6 to 12 months), and helps an agile team to become a well-oiled machine.  Regular cadence or pattern also reduces unplanned, unexpected, interrupt-driven work that is very damaging due to sudden, unplanned context switches with resulting loss of productivity.

For all these activities shown on a regular cadence in Figure 3, the ScrumMaster working with the team members must set aside adequate capacity: 4 hours for sprint planning, 4.5 hours for 9 Daily Scrum meeting (preparation and attendance), 4 hours for Analysis of the next sprint, 3 hours for Sprint Review, Sprint Retrospective and Celebration – a total of 15.5 hours of capacity is needed for each member for these activities, and that capacity for each member is not available for the design-development-testing-defect fixing work for the current sprint.  If you are interested in calculating the agile capacity of a team after allocating capacity for all these activities, please see my Agile-capacity-calculation blog on the subject.

Solution to the challenge of managing the risk of doing wasteful work (2CP): An important reason why teams fail to deliver stories or backlog items in a sprint is that they were not understood properly when they were committed to the sprint plan during Sprint Planning.  As Dean Leffingwell explains in his Agile Software Requirements book (page 211), from a timing perspective there are three opportunities to do this conversation and confirmation for each story.

  • Prior to the sprint: This is what I have advocated in this blog by stipulating to engage in this conversation and confirmation only one timebox ahead.  Doing it more than one timebox ahead will increase the risk that some of those stories may not get into any sprint commitment as they get trumped by higher priority stories, or they may be removed from the product backlog altogether due to changed business conditions.
  • During the Sprint Planning Workshop:  This workshop is limited to approximately 4 hours for a two-week sprint.  In this short time box, the team has to not only converse and confirm the stories, but do story effort estimation and all other tasks related to sprint planning.  The team may find it difficult to get the time needed to complete the conversation and confirmation for each story, or the product owner simply may not have answers to some of the questions and most likely there is no time in the workshop timebox (only 4 hours) to get the answers by contacting users, customers and stakeholders.
  • During the actual sprint: If the team feels sufficiently confident that conversation and confirmation about a story can wait until the actual sprint due to uncertainty about the story’s business needs, then the conversation and confirmation for that story may be completed along with its implementation in the actual sprint if the story is of sufficiently lower priority.   However, keep in mind that the story was committed to the sprint during its sprint planning without proper conversation and confirmation (and hence with either no estimate or a very rough estimate).  This situation carries some risk and is not ideal.

I recommend that you complete the analysis of as many high priority stories as possible one timebox ahead of the sprint in which they will be implemented, try to complete as much analysis as possible for some of the lower priority stories during the Sprint Planning Workshop, and leave very small number of analysis questions to be resolved during the actual sprint if you have to.

In my coaching engagements, I have seen agile teams transitioning from sequential sprint execution model to the pipelined sprint execution model after 2 to 4 sequential sprints under their belt, and then with experience (inspect and adapt) getting better at the pipelined model.  This is kaizen (continuous improvements) in work, resulting into higher throughput, improved quality, and increased team morale and work satisfaction.

Have you tried the sprint pipelined model?  What is your experience?
Are you interested in starting your own sprint pipeline?

I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).


Healthy Planning with Physicians Mutual

Rally Software - Agile Blog -

From life, dental, and accident insurance to Medicare supplements and annuities, the Physicians Mutual family of companies has spent the last 100+ years building nearly $3 billion in assets and consistently earning high ratings for its financial strength.

The Enterprise Technology Group (ETG) at Physicians Mutual is responsible for strategic and portfolio planning as well as project budgets, managing a portfolio of both Agile-driven and traditional project-driven work. So when it decided to go Agile in 2012, it wanted to choose a solution that would unite strategic and financial planning across multiple business units, and bring visibility and efficiency to its development work.

The PPM/ALM solution provided by the Rally and Planview partnership gives Physicians Mutual an end-to-end portfolio management platform -- from intake, to planning, to execution, to delivery. By connecting “above the line” strategy with “below the line” execution, the Rally and Planview partnership provides capacity and resource planning, strong financial reporting, and a holistic view of work regardless of project methodology.

“What attracted us to both was the partnership -- the two companies really partnered with each other in order to satisfy the customer’s needs,” says Joan Bohannon, Project Manager, PMO Operations, at Physicians Mutual.

Bohannon explains that the company has reached the point where mid-range planning is a key ingredient in helping teams understand what the strategic priorities are, and how those strategies break down into high-level features. “The teams then take those [high-level features] and look to figure out what it’s going to take to develop those features to the business.

“Without mid-range planning, we wouldn’t have any type of pulse on capacity to get those things done, nor any indication that we were working on the right things.”

"Mid-range planning has been very healthy for us.”

The Planview and Rally integration has brought Physicians Mutual a marked increase in transparency and an earlier assessment of risks. Other results:

  • A 50% increase in major product releases year-over-year
  • Substantial cost savings over three years from consolidating solutions and eliminating waste
  • More products to market, faster -- from four major product releases per year to six, along with minor iteration releases
  • Elimination of duplicate entries, meetings, and other process documentation along with efficiencies resulting in over 1,000 man-hours saved per year
  • No more hours spent building reports to support financial analysis, accounting, and statutory reporting
  • Increased visibility into work and resources, leading to better project management and risk mitigation

Hear more about Physicians Mutual Agile Journey at RallyON 2014 in Washington, D.C., June 9 - 11, 2014, or read the case study.

Hannah Shain

Yet Another $163B Waterfall Disaster

Scrum Log Jeff Sutherland -

The F-35 Is Worse Than HealthCare.govVocative.com - Eric Markowitz, 25 Mar 2014The $400 billion jet project is the most expensive weapon the Pentagon has ever purchased. It's also seven years behind schedule and $163 billion over budget ...And here’s the kicker: According to a 41-page Government Accountability Office (GAO) report released yesterday, the F-35, which has yet to fly a single official mission, will stay grounded for at least another 13 months because of “problems completing software testing.”
What GAO Found Delays in developmental flight testing of the F-35’s critical software may hinder delivery of the warfighting capabilities the military services expect. F-35 developmental flight testing comprises two key areas: mission systems and flight sciences. Mission systems testing verifies that the software-intensive systems that provide critical warfighting capabilities function properly and meet requirements, while flight sciences testing verifies the aircraft’s basic flying capabilities. Challenges in development and testing of mission systems software continued through 2013, due largely to delays in software delivery, limited capability in the software when delivered, and the need to fix problems and retest multiple software versions. The Director of Operational Test and Evaluation (DOT&E) predicts delivery of warfighting capabilities could be delayed by as much as 13 months.

Re: Taylorism strikes software development

Alistair Cockburn -

Nah, the essence of Taylorism isn’t scientific management per se, but management of OTHERS using scientific methods.

In Scrum for instance we value both self-organization AND scientific methods. Call it scientific self-management if you want. Definitely not Taylorism where the worker is the study object of the scientist. Rather the worker being the scientist.

Too sad I couldn’t come to Scandev this year.

-by Ola Berg on 4/5/2011 at 5:16 AM

Nice observation, Ola. Thank you for that.
If there wasn’t such intense social pressure on THESE people to adopt what THOSE people like to do, I’d feel more comfortable. However, that THESE/THOSE split is exactly the OTHERS that you capitalized in your first sentence. So I stay worried.
thanks – best, Alistair

-by Alistair on 4/5/2011 at 5:19 AM

I have this uncanny feeling too, but my perspective is more from the Cynefin framework, not so much Taylorism. Although the general word of mouth is that software development is in the complex domain it seems that the pressure is on being it in the complicated domain with all its ‘good practices’.

Maybe the good thing is that by discovering that we have more control over our technical area of expertise which makes it possible to move parts from the complex domain into the complicated domain and from the yet-chaotic domain into the complex domain.

Or maybe people are just looking for security, for ease of mind, for a silver bullet.

-by Maurice le Rutte on 4/5/2011 at 5:57 AM

In what way is Scrum less “Tayloric” than Kanban?

And what´s bad in identifying software development as consisting of necessary steps (like req.analysis, design implementation, review, quality assurance), putting them in a sequence and applying findings from the Theory of Constraints?

What´s bad in evolving the industry onto a level where not all shops have to reinvent the wheel and find their conventions and rules? Art and craftsmen of all sorts since long have identified “best practices” to reach certain results – which does not preclude creativity but rather gives creativity a focus.

-by Ralf Westphal on 4/5/2011 at 6:08 AM

IMHO I reckon the key difference between Taylorism and Lean/Agile is that Taylorism begins with the assumption that workers are feckless, and Lean/Agile begins with the assumption that workers are intelligent and engaged. From these two different starting points you get two very different approaches. Taylorism and Lean/Agile both use scientific methods, but the difference in the basic motivations lead to vastly different applications of the methods and data.

-by Clifford Penton on 4/5/2011 at 6:53 AM

David Anderson spoke about two waves of lean reception in the west. The first without a concept of ‘variability’. It’s the reception of ‘the machine that changed the world’. And in the software world – I think – it’s the reception of Mary and Tom Poppendiek. Reading ‘Lean Software Development’ there is the sense of having read this content in other terms in others introductory XP and Scrum-Books. Kanban and Anderson are different. I think the conceptual cause is his notion of variability. And this could be what your term Taylorism addresses. Kanban as a tool to reduce variability. It’s the counterpart of your engagement on craft, creativity and personalities. In other words: the grassroot-movement of agile software development has crossed the chasm of market economy. But – my hope – the market economy, which adopted agile, will slowly shift to become more creative and more human.

-by Jens Himmelreich on 4/5/2011 at 8:38 AM

I thought this was about uncovering better ways of developing software by doing it and helping others do it.

Perhaps there is a lot less uncovering now than there was in the 90s, and more ‘helping others do it.’

I suppose I could view this as Taylorism if I saw these popular practices begin to stifle disruptive innovations in how we work. My instinct says that is not happening at all, but perhaps I’ll look at this differently in another 10 years.

-by ksteff on 4/5/2011 at 10:08 AM

How about “Everyone needs to do it this way until, individually, they find a better way”? In our organization two product groups adopted agile in two very different ways. One saw agile as a major change and managed it as such. They completely changed their organization, and the way they worked. The other tacked on agile practices to their existing structure. About 18 months in and the group that completely changed the way they worked, and adopted a “standard” way of doing agile appears to be the more advanced organization. Is everything perfect, no, and they are now allowing deviations from the standard to achieve better performance. Is there value to having everyone work one way, yes, and is it always the right answer, no. The question is, at what points during the evolution of the organization does it help to apply “Taylorism”?

-by Robert Fayle on 4/5/2011 at 10:44 AM

How about “Everyone needs to do it this way until, individually, they find a better way”? In our organization two product groups adopted agile in two very different ways. One saw agile as a major change and managed it as such. They completely changed their organization, and the way they worked. The other tacked on agile practices to their existing structure. About 18 months in and the group that completely changed the way they worked, and adopted a “standard” way of doing agile appears to be the more advanced organization. Is everything perfect, no, and they are now allowing deviations from the standard to achieve better performance. Is there value to having everyone work one way, yes, and is it always the right answer, no. The question is, at what points during the evolution of the organization does it help to apply “Taylorism”?

-by Robert Fayle on 4/5/2011 at 10:54 AM

Toyota has an ongoing success pattern in Toyota ‘lean’. It adapts locally, one plant does things differently than the next. It engenders lots of new ideas. It’s founded on ‘go look and see’ – true scientific method. Western ‘lean’ lives in lots of coaches creating better ways, in the office – not so much ‘go look and see’ – not true scientific method.

I think sima-Taylorism is arriving in the encrusted build-up of better ‘in the office’ ideas being applied.

Pattern: Pity the poor dumb newbys trying to explore the mass of new materials – no patterns at first. Add advice. More layers of advice > small divergent hills. > Route finding, compass skills. Ask Taylor for help.

-by vic williams on 4/5/2011 at 12:03 PM

Re: “In this article, he shows the worldview of lean as that of production” I spotted that the quote from Mary and Tom’s introduction was “we believe that software development is similar to product development” – Product development (as in design the car) as opposed to Production (as in build the car).

In case that helps.

-by Bob Corrick on 4/5/2011 at 12:28 PM

If I understand the thrust of this article, it is that we shouldn’t be forcing teams to “do the XP practices” because now we are just the “new boss – same as the old boss”. If I miss the point, please flame me until I learn.
But if that is the point, I think it is important to know what has come before you if you are to move forward. We expect people on our teams to know and be proficient at the defined XP practices if they are going to determine their own way.

-by Jim Kimball on 4/5/2011 at 6:34 PM

I think Cliff hit on it, but I will elaborate on his point. Taylorism consists of 4 points:

1. Replace rule-of-thumb work methods with methods based on a scientific study of the tasks.

2. Scientifically select, train, and develop each worker rather than passively leaving them to train themselves.

3. Cooperate with the workers to ensure that the scientifically developed methods are being followed.

4. Divide work nearly equally between managers and workers, so that the managers apply scientific management principles to planning the work and the workers actually perform the tasks.

I think point #4 is where you see the major divergence between Lean systems as devised by Toyota. In TPS, the people who use the standard own it and can change it. Taylor explicitly said there were “managers” who made the standards and “workers” who followed them. This is a big point and I wouldn’t gloss over this difference

-by Brian Bozzuto on 4/5/2011 at 10:59 PM

Reading your post and the comments were the best 45 minutes of my day :-)
I follow in the steps of Cliff and Brian. Well put.
My addition is the fear of US/THEM and OTHERS. I constantly fight the often found argument for applying a process, method or practice: “Because someone told me/us so.”
The decision should be made by me or us and should be based on a need or whish.

-by Arne Åhlander on 4/6/2011 at 3:34 AM

The Taylorism/Kanban possible mix has always worried me. It’s something we need to keep an eye on. I have concerns that AndersonKanban could be a trojan horse to lead a whole heap of Tayloristic and 20th century business practices in the back door.

(Or front gate to continue the Troy Metaphor.)

I hope the Kanban movement continues to grow in more interesting, creative directions. Perhaps towards the Scrum world.

-by Nigel on 4/6/2011 at 11:35 AM

>I add chapters on craft, creativity and personalities, not as compensation, just as part of the mix. I don’t see others putting those into the mix.

It’s a worry. I don’t see people doing it either. I had a try at doing it myself last month, with a talk on the people side of agile. It was a lonely experience, because I felt that I was saying things that few others were saying.

I wonder if too much “social momentum” has built up behind the process-centric/”Taylorist” view of agile. Consequently, learners don’t ask to learn the craft-centric view (they may not even know it exists!) and (most) teachers don’t teach the craft-centric view – since one feels like a lonely heretic if you do!

Having said that, there is a strong (largely unrecognized) need for learning the craft/people side of things. On the rare occasions when it is presented, I suspect feedback is very positive. (At least, it has been in my recent experience).

Brian's first point re Taylorism, above, is interesting: "Replace rule-of-thumb work methods with methods based on a scientific study of the tasks". IMHO, if scientific study is done, then what you find is exactly "people + craft". (As in your studies Alistair, in Schon's work from the 80s, and James Bach's recent talk on the Myths of Rigour). So, regarding your concern about an overemphasis on analytical processes in agile, perhaps the problem not really Taylorist. Instead, perhaps its actually Taylorism done wrong. Taylorism done _right_ starts with science, and when it comes to creating software, the science leads us to favour "people + craft" over "process + analytics".

Finally, in most cultures, we are not very good at knowing what to do about "people + craft". We come through education systems which encourage us to think that expertise results from one-time aquistion of pre-defined knowledge (very “Shu”). I don’t think our minds, or our corporate cultures, easily embrace the idea that true expertise really comes from a lengthy period of honing one’s craft.

-by John Rusk on 4/6/2011 at 8:21 PM

This reminds me of something that has bothered me for a long time. It has become fashonable to denounce best practices as inherently evil. People cite innumerable examples of best practices stifling change and not taking context into account. At the same time even the most dogmatic opponents of best practices go to conferences and listen to other peoples accounts of how they solved their problems.

-by Niklas Bjørnerstedt on 4/7/2011 at 7:26 AM

This reminds me of something that has bothered me for a long time. It has become fashonable to denounce best practices as inherently evil. People cite innumerable examples of best practices stifling change and not taking context into account. At the same time even the most dogmatic opponents of best practices go to conferences and listen to other peoples accounts of how they solved their problems.

-by Niklas Bjørnerstedt on 4/7/2011 at 7:34 AM

Software development is production, in the economic sense of the word. What it’s not, is mass (aka assembly line) production.

Forms of production range from one-off projects, through job shops performing custom work, to mass and finally to flow production, each successive type more predictable, repetitive, amenable to automation. In my opinion, commercial software development usually falls somewhere between the project and job-shop models depending on how the work is organized. Calling it production does not disparage the work or the craftsmanship of the workers.

Suggesting that analysis and the scientific method are somehow bad in and of themselves is a flat-earth worldview that dead-ends progress. The idea that we’ve already found the “best way” is a symptom of a lack of process analysis, not an excess of analysis.

-by larry white on 4/7/2011 at 7:42 AM

I share your general concerns, but do not recognise your interpretation of Taylorism and Scientific Management (both dysfunctional, at best, imo).

Hence I do not accept your conflation of Taylorism and some aspects of Agile, Lean practices. For me the heart of Agile (and Lean) is Respect for People.
If people want to do “scientific” things like compile metrics, then all well and good (let’s respect them for those choices). And if they want to do things a certain way because others are, or because it’s the norm, then again let’s respect them for that.

Most of society has a profoundly Newtonian / Analytic/ Taylorist view of life in general. I think it’s inevitable then, that many agilists, especially those new to the field, will bring that world-view with them into the workplace.

We must all try to help them (and ourselves) understand these (Newtonian, Analytic, Taylorist) assumptions – and the implication of those assumptions, too. With such understanding, maybe some folks might then seek an alternative (and BTW more “effective”) world-view, such as the Synergistic, or even the Chaordic.

- Bob @FlowchainSensei

-by FlowchainSensei on 4/7/2011 at 7:50 AM

Niklas: best practices aren’t evil, they’re just not always best. What is best for me right now may be worst for you.

-by Tobias Fors on 4/7/2011 at 8:27 AM

Niklas: best practices aren’t evil, they’re just not always best. What is best for me right now may be worst for you.

-by Tobias Fors on 4/7/2011 at 8:28 AM

Talking about TPS (and not LPD as Toyotas way of doing PD has been oft mentioned), Brian writes:

“In TPS, the people who use the standard own it and can change it.”

I can’t remember reading that anywhere but I rarely remember so much, I doubt very much it pans out that way in practice and my understanding is that this very point is at the core of what separates sociotech based plants from lean based.

There may be problem that comes from the outlook behind adoption of some lean techniques: The danger is getting a “grey” production feel where creativity is stifled. I believe I’ve seen it happen. A problem may be in common attitudes of many creative minds and personalities toward structured processes. Attitudes shaped from our culture, perhaps like stereotypes.

Thanks for the thoughts.


-by mawi on 4/7/2011 at 9:14 AM

Software development is production, in the economic sense of the word. What it’s not, is mass (aka assembly line) production.

Forms of production range from one-off projects, through job shops performing custom work, to mass and finally to flow production, each successive type more predictable, repetitive, amenable to automation. In my opinion, commercial software development usually falls somewhere between the project and job-shop models depending on how the work is organized. Calling it production does not disparage the work or the craftsmanship of the workers.

Suggesting that analysis and the scientific method are somehow bad in and of themselves is a flat-earth worldview that dead-ends progress. The idea that we’ve already found the “best way” is a symptom of a lack of process analysis, not an excess of analysis.

-by larry white on 4/7/2011 at 9:45 AM

For me the crux of what you’re saying is this statement:

Agile views software development as a process for building a consensual theory of the world: with an artifact being a byproduct – an expression – of that theory.

I agree with the statement that agile is a process for building a consensual theory of the world, but to me the artifacts are the MEANS by which the consensus is built, not just a byproduct. The shared focus on creating something of value is the ground from which agile consensus is built, whether in a small collocated team or in a huge distributed one.

From that standpoint, I agree with you that ten years on, even agilists need to make a specific effort to keep refocusing on people rather than getting so caught up in the process. And those of us who identify as agile but then define it in terms of automated test coverage or shortness of stand-up meetings have missed this fundamental point. It seems like the challenge is to take on mastery of new techniques without losing focus on the shared delivery of value which ought to be holding our teams together.

-by Elena on 4/7/2011 at 11:41 AM

Successful Software Development requires 2 components — human creative abilities supported by the necessary talent and knowledge, and a good process for managing / predicting the project.

We can easily observe, pick apart, analyze and reason about the process. But the first part is just magic. Where does creativity come from? Why can some people do it while others can’t? What is it that causes good ideas to come from the mind of good developers? We really just don’t have a clue.

So we obsess about the part we can understand, and over-optimize it. Of course, tremendous benefits have come from paying attention to process; but it can be easy to forget that the main thing is the part we don’t understand — the mysterious ability of the human brain to create things.

-by Charlie Flowers on 4/7/2011 at 6:07 PM

Does not Scrum ask people to work as a team and self-organize? Does not Scrum ask someone to prioritize and the team to respect it? Does not Scrum ask someone to remove impediments? Does not Scrum ask a team to build an increment every sprint? Does not Scrum ask to run Sprints? Does not Scrum require transparency?

Sorry, if you think XP guys are forcing people to follow best practices Scrum does exactly the same.

By the way, Kanban is the less invasive approach. Kanban is just an improvement/change management. Kanban has no rules. Kanban respects people including managers. I use Kanban to map the mess, making it visible, and the team will be empowered to fix it “the baby step” way.

Just my 2 cents. This post can be classified as FUD. Not much your style Alistair.

-by Rodrigo Yoshima on 4/8/2011 at 9:56 AM

For me, kanban is a tool to visualize work.

You can use it with Scrum. It’s just a board with sticky notes on it.

All it asks is that you understand what you are doing and that you limit your work in progress.

Yes, some people want to add more process to it than necessary. That’s because most process is unnecessary. But people use it as a crutch when they don’t have control or know what is going on. That crutch, in turn, becomes politicized and deified, until we get unproductive conversations over value creation.

If we all just lost the dogma and looked at good ideas, we’d have a much better discussion.

Jim Benson

-by Jim Benson on 4/8/2011 at 11:32 AM

Hi Jim,

Agreed, but kanban became “Kanban” with all the associated paraphernalia and that is where the problem started.

I’m glad that someone actually stated what Taylorism actually is. The TPS builds on Taylorism, sharing 3 out of the 4 points. The last point has more to do with culture then science and was ditched by the Japanese in favor of common sense.

CAS theory moves us beyond newtonian science, which is deemed inappropriate by some when it comes to software development (software development is not manufacturing). This is the Agile movements big break with the past.

Alistair is raising a concern, which I think is a valid one. Lets not forget that the most common management approach is still Scientific Management, aka Taylorism. This is still the corner stone of Western Management culture.

If Taylorism as remoulded itself and is making its present felt through the back door, it wouldn’t be the first time. Change is difficult, and it is up to us to make sure that the new thing isn’t a revamping of the old thing, but in a different guise :)

-by Paul Beckford on 4/8/2011 at 1:21 PM

Hi Jim,

Agreed, but kanban became “Kanban” with all the associated paraphernalia and that is where the problem started.

I’m glad that someone actually stated what Taylorism actually is. The TPS builds on Taylorism, sharing 3 out of the 4 points. The last point has more to do with culture then science and was ditched by the Japanese in favor of common sense.

CAS theory moves us beyond newtonian science, which is deemed inappropriate by some when it comes to software development (software development is not manufacturing). This is the Agile movements big break with the past.

Alistair is raising a concern, which I think is a valid one. Lets not forget that the most common management approach is still Scientific Management, aka Taylorism. This is still the corner stone of Western Management culture.

If Taylorism as remoulded itself and is making its present felt through the back door, it wouldn’t be the first time. Change is difficult, and it is up to us to make sure that the new thing isn’t a revamping of the old thing, but in a different guise :)

-by Paul Beckford on 4/8/2011 at 1:41 PM

Any process exists because, although we would love to think otherwise, not everyone can be empowered to make their own decisions. In fact, most people need help deciding how to move forward.

That’s when we come in with processes.

And, like any other area of human knowledge there is always a group of people with a greater truth than others trying to impose their perception of the world.

And, like any other area, not everyone follows.

And we will keep evolving.

-by Pedrob on 4/8/2011 at 9:07 PM

Taylor called for managers to make the decisions regarding the working process and workers to execute management’s edicts. In contrast, Kanban’s pull system empowers workers to make choices as to what work they will do at what time. WIP limits are set by agreement of all stakeholders. If management were to press for artificially high WIP limits, the result would not be increased output, but rather impeded flow.

Although David Anderson calls for scientific analysis of results to determine success of a Kanban effort – this is not an element of Kanban itself. Certainly other tools such as empirical observation and satisfaction surveys could be employed in addition or as alternatives.

-by Chance Gold on 4/9/2011 at 2:32 PM

How did a thoughtful post turn into a red-herring attack on Kanban? If you haven’t read the book or participated in a thoughtful discussion on Kanban with an informed practioner – then don’t chime in. Alistair’s point is that there is danger with all of the practices that people implement them without understanding the underlying principles – whether its Scrum, XP, or Kanban. There is some risk of gurus deciding they “have the answer” and now need to tell other people “the best way to build software” – whether its Scrum, XP, or Kanban. We see this everyday in businesses.

The fact that a team can get some data out of Kanban and use it to determine how to focus is valuable – not Tayloristic. The Kanban community does not agree with the Poppendieck’s direct translation of Lean manufacturing approaches to software development. They view this approach as value destroying and de-humanizing.

Kanban recognizes variability, the notion that people that do the work have the best understanding of what is happening, and the understanding that de-humanizing the environment is contrary to what is best for knowledge workers. The Kanban community suggests understanding the environment and establishing a process of ongoing improvement – using visualization and limited WIP in the context of variability and knowledge work.

Taylorism is destructive. So is TQM. Kanban is not Taylorism. Kanban is not TQM (and we have had this discussion for over a year). Just arbitrarily connecting two related things and then going after the red-herring worst possible case is irresponsible.

Alistair has a valid point to contemplate. When we work with companies (our own or as trainers and coaches) are helping companies improve software development using appropriate tools from Kanban, Scrum, or XP – or do we dictate the “one true way.” Red-herring and uninformed discussions are of no value in this community.


-by Dennis Stevens on 4/10/2011 at 9:52 AM

H Dennis,

No one is attacking Kanban. Jim mentioned kanban and I responded in that context. The same response is equally applicable to XP, Scrum or any codified set of practices, that are implemented in a way the emphasises process over people.

I didn’t mention TQM in my response :)

-by Paul Beckford on 4/11/2011 at 3:08 AM

Oips… facilitator intervention here… please stop name calling and accusation. I will delete any such remarks. Keep it clean, gentlemen, just discuss the topic and not each other. Thanks —- Alistair.

-by Alistair on 4/11/2011 at 12:46 PM

One missing ingredient in this debate: what do industrial product developers do?

In my review of that literature I have found very little support for concepts like statistical process control applied to the development of novel products for manufacture.

Would a manufacturing professional view this debate as perhaps a little naive? Product development in the atom-space is just as risky, uncertain, and iterative as software development in the bit-space.

Don Reinertsen has covered this ground in great depth and understands both bits and atoms.


-by Charles Betz on 4/11/2011 at 1:45 PM

Not sure why that double posted, apologies.

-by Charles Betz on 4/11/2011 at 1:58 PM

Charlie – apologies for the double post on my side. It happens sometimes, and I haven’t yet worked out why. Alistair

-by Alistair on 4/11/2011 at 4:15 PM

My fear with respect to lean has always been implementations based on missunderstandings. For instance that “Standard Process” means the only (and best) way, instead of the way we work until we invent a better way or working. The focus on flow may result in implementations that institutionalize handoffs (which by Mary and Tom Poppendieck actually identifies as one sources of waste in their book). Managing flow and queues are tools to improve the cycle time, so we can get faster feedback – but we must also remember to have collaborative cross-functional teams that move together, as pointed out in “The new new product development game” article.
I second Charlie that Don Reniertsen’s work has importent points for both software development and product development.

-by B Rasmusson on 4/12/2011 at 9:48 AM

Let me admit first of all that I know nothing about Taylorism, Kanban, and a slew of other topics covered in Alistair’s blog post and the comments on it. But with 10 years as a BA in a waterfall environment, and having just been trained and transitioned into Agile for a Fortune 50 company 3 months ago, one thing strikes me as universal in both this discussion and common practice: methodologies have very little value apart from the quality of the team that adopts them. If a team has done well in waterfall and then adopts a lean methodology of one kind or another, the very fact that they’ve taken the initiative to make the change is an indication that they are likely to succeed. If a team has done poorly and adopts a new methodology and succeeds, I find that’s usually the result of the engagement of team members and management that was absent prior to the change more than it is due to the methodology itself. As often as not, the team falls apart again as soon as the stakeholders pronounce the transition/migration “done.”

From the “worker bees” to the highest level stakeholders, methodologies consistently fall apart on one point: no one methodology can be universally applied. It is the nature of the beast (human, manager, developer – whatever beast you pick): we wait and hope for a “once and done” approach that will guide us through waters made ever murkier by the pace of change and the almost incomprehensible possibilities that technologies offer. If that weren’t enough, most methodologies fail colossally in accounting for one very interesting paradox: we hope for the once and done definitions of a process that will guide us through the unknown; but the truly productive worker – of any stripe – is never satisfied in a static state.

If it’s true that Taylorism starts with the assumption that workers are feckless and Agile starts with the assumption that workers are intelligent and engaged, then they’re both going to fall apart on some point – because both assumptions fail at some point. Give me a team of 10 people and a week to track them, and I’ll give you a range of 20 to 30 degrees between feckless and engaged/productive – with some members fully running the gamut in that short time!

Granted, all methodologies have to start somewhere. I’m feeling pretty partial to Agile myself – having seen more productive discussion come out of a co-located Agile team in 10 minutes than I have seen come from some waterfall teams in 10 months. That said, “best” of anything is always, ALWAYS going to be a moving target. If it weren’t simply the complexities of people that make that true, then the compounding of complexities by N number of times (i.e., number of team members) makes it true.

As a general rule, people rise (or sink) to a level of expectation held by a person in authority over them. If a manager is visionary, engaged, communicative, and expects his workers to be the same, he can generally get the same out of his team (or keep changing up team members until he does), regardless of the methodology. I know there are scientific measurements of this approach and that approach that offer hard evidence for the efficacy of processes. But I recently heard a talk by a former IBM executive who has published on a methodology he devised where he extolled the virtues of his approach for an hour – only to say at the end that the astounding results he achieved in his first project with that approach have never been replicated.

If Alistair’s point is that it’s distressing to see the pendulum swinging back in a direction opposite the one that took us to lean, there is this consolation in it: it is a luxury of creative, productive people to worry about how to get work done better. Whether it is a cultural phenomenon, the social degradation of recent decades or the historical manner of being, there are way too many workers out there who care neither for the end product nor how it’s produced. Much less do they care for the angst over how the future products are conceptualized and realized. The best tend to stay the best and the others tend to stay the others regardless of what methodology they’re using at any given time. Everyone pat yourselves on the back. Just a willingness to engage in the discussion (and the passion to be heated about it) rates you in the first group!

-by Karen C. on 4/13/2011 at 6:52 PM

If you replace “manager” and “worker” with “architect” and “developer”, I think the lean/Taylorist caution does apply to software. A lot of development groups are having solutions imposed by architects that stand apart from the day to day production process. Unfortunately, the architects often view development as low-level commodity work that they’ve found a way to transcend and rise above.

-by Michael D. on 4/15/2011 at 9:34 AM

Agile is not evolving when it embraces Taylorism, it is devolving.

Mike Rollings
Research VP – Gartner

Here are several related posts:
Taylorism is a Pox upon Agile

Replacing Taylorism as our Management Doctrine

Context breaks Taylor’s hold on strategy

-by Mike Rollings on 4/27/2011 at 9:41 AM

Hi, Mike! Great post – thanks for dropping by and sharing those links/thoughts. Alistair

Late to the conversation…

Tayloristic thinking is about controlling work/tasks via process and not via people. People are components that are plugable to the process. Measurement is via output of the process.

It is human nature that since we can’t totally control all aspects of the process, i.e., people, that we need that lack of control (lack of trust) to be compensated by some method. That ends up being more processes, standards, reporting, etc…. When one mistake occurs we add more process so it doesn’t happen again, instead of recognizing for what it is, a mistake. Now everyone pays the price with more process, policy, and bureaucracy.

The ongoing fight is to balance process with people. Creative, innovative people leave when process becomes too heavy. People at the team level need to decide what and how much process they employ. I cringe at the statement “that won’t work for how we do agile”. Don’t fit people into processes, but processes need to support who people are and how they work. That is harder work to do.

Now that agile/lean team development is mainstream it is in the cross hairs of people whose responsibility it is ensure ordered process and uninterrupted smooth running organizations. The notion of a chaordic team is contradictory to their mission.

The need change is that the people in control need to be more trusting. The larger the organization the harder that can be. If people are not held accountable for their actions then it is impossible.

If a team has a miss then discuss the real reason behind it, don’t automatically add process. What was the root cause? Often the root cause is what people do not want to see, because it is not coherent with the story they tell themselves and others. It affects how the organization operates and thinks.

-by Riley Horan on 6/24/2011 at 1:03 PM

Nice comment, Riley. Thanks. (Alistair)

Don’t blame Taylor. Reductionism is in our genes. We have an endless need to simplify complex processes or situations to reach an “understanding”, misleading us to think that we are in control. The problems arise when we start to organize our business using the template from a task break-down of a software development process (losing knowledge in each hand-off as well as introducing waste). For this, we can blame management for embracing scientific management. Lean and Agile are tools to make a shift from all this. Speaking Taylorian with management is a good way to get their attention and things going.

-by micke on 6/29/2011 at 8:11 AM

Thanks, Micke. I just want to say at this point that I’m enjoying the thoughts you all are offering in these posts, so thank you for that. Alistair

It occurs to me, re Taylorism, that I’ve been on jobs where I had to change my way of working to a much less efficient style because I was setting a bad example – meaning that it became apparent that coworkers who thought they understood what I was doing and why, were going to **** up royally if they kept imitating me (imperfectly). Often this was because they would “steal” part of a method, but not, say, safety checks that seemed to them to be mostly unnecessary. I’m sure most people find themselves in this situation from time to time and make the sensible choice: namely, to adopt the less efficient method and blend in.

-by on 10/20/2011 at 10:29 PM

Nice comment, thanks … but please be so kind and sign your actual name – this is a friendly site, and is made more friendly when people use their names, thanks. Alistair

I think at least part of the problem here is the inability (or disinterest) for “most” people to move beyond shu-level practices, which are (and should be) typically presented in a Taylorist model (this is the way, the right way, and the only way).

The understanding of “there are many paths to the top of the mountain, some easier some harder” requires people to climb the damn mountain more than once. How often do you meet people in our business that actually have?

-by Jonathan House on 4/9/2014 at 5:51 PM


The Evolution of z/OS Development

Agile Connection -

Kristin Cowhey explains how OS development has evolved throughout the years and what that means for developers and tech personnel. With legacy developers leaving the workforce, there’s a dire need to replace the knowledge in order to maintain the mainframe systems and applications that are still in use today. 

Agile Planning Fundamentals with TeamStart

Rally Software - Agile Blog -

Agile Planning: it’s not an oxymoron.

On Tuesday, April 15, our TeamStart webinar series will answer your questions about Agile Planning. Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give good Q+A. We'll talk about making and keeping commitments, using tracking and metrics to predict delivery, and planning levels with time horizons.

Here are a few questions from past Agile Planning webinars:

  1. How does the product owner role fit into Agile Planning?
  2. Are there guidelines for setting up good planning estimates?
  3. If the team is not able to complete a story before the iteration ends,  or if a critical change is requested, how do we respond?

From an Agile Planning perspective these are related questions. Let’s take a look at the answers to see why.

1. How does the product owner role fit into Agile planning?

Answer:  A product owner initiates and translates the product roadmap into a manageable product backlog. He or she participates in daily standups and manages the product dashboard. The product owner communicates with internal teams and the product manager, to understand the features and requirements and support the release planning and sprint planning exercises. It’s also the product owner’s job to allow the team to manage itself and understand Agile estimation approaches.

5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up, Hubert Smits

2. Are there guidelines for setting up good planning estimates?

Answer: The principal guideline when estimating user story size is to employ a comparative approach. For example, rather than estimating in absolute terms, such as hours or days, you use abstract "story points" to compare the sizes of work items with past work the team has completed. Using an example the team is already familiar with helps you establish a baseline. By contrast, task size should be estimated in hours, since a task should be small enough that it doesn’t span more than a working day (about six hours.)

The estimation of stories done in abstract values happens continuously, and well before iteration planning; whereas task estimation is done once during the iteration planning meeting, immediately before the team votes to commit to the proposed work.

3. If the team is not able to complete a story before the iteration ends, or if a critical change is requested, how do we respond?

Answer: When the scope of a user story becomes larger -- either because you underestimated its scope or because a change request comes in -- you should finish the current iteration as planned, and re-plan the remaining iterations in the release. In a situation where the team still has a fixed delivery date, you must work with the business to determine what other committed-to features or functions may be sacrificed to continue to work within the timebox limits. Teams should review burndown charts daily, so that you can spot problems early and mitigate them. When it’s necessary to re-estimate and re-prioritize features, you should signal to the business and stakeholders as soon as possible.

I bet you have at least three questions about Agile! Learn more about Agile Planning. Join Tuesday’s TeamStart webinar.

Rob Ward

Two-Layered Scrum for Large IT Organizations

Scrum Alliance -

Large IT organizations with several business initiatives and multiple projects being executed in parallel require agility and collaboration at two levels: the project level, which is always where it starts; and the application level, which is often overlooked or at least not well defined. . . .

Writing in an Agile World

Agile Connection -

Sarah Johnson explains the role of writing in an agile world and how to educate your team members. Remember, agile takes into account that each situation is unique, and you need to determine what makes the most sense for your particular Scrum team.


Scrum Alliance -

It takes time for a Scrum team to reach the high-performing stage. But you, as ScrumMaster, can compress that time. How?


Alistair Cockburn -

Dov said, “Sometimes there is no question seeking an answer and there is no answer trying to be found, there’s just a QuAnswer that happens.”


“QuAnswer” [kwanser] thx Dov Tsal Sela: when there was no Q, hence was no A for it; but it just appeared in the dialog. @malk_zameth saw it appear as a QuAnser itself. Today at La Pere Tranquille, Paris :)


Subscribe to - Business Coaching Phoenix AZ  aggregator