Feed aggregator

The Agile Coach on Focus

VersionOne Agile Management Blog -

To me, nothing is more frustrating than context switching (i.e. multi-tasking). It takes away from our ability to focus.

As a result we’re far less productive. We often produce more bugs, and are generally more stressed out.

You may have gone through this exercise (or one like it) in an Agile Bootcamp or Scrum Course; it’s called ‘Multi-tasking is worse than a lie’. Here’s how it goes…

Get a piece of paper and write the sentence: Multitasking is worse than a lie

Every letter you write, you should immediately write a number just below it, starting with 1 and going through to the number 27 as you reach the last letter in the sentence.  So you write “M” and then 1, you write “u” and the below it 2 and so forth.  You keep this up until last letter of the sentence and you time yourself.

Now try writing the sentence in full followed by the numbers 1 to 27 in full. Again, time yourself.

What I’ve found over and over again is that, on average, it takes just a little more than half the time in the second instance. We’re still doing the same amount of work, mind you.

Now think about how simple this exercise was. And about how complex the development of software is. And compound that by the number of projects and tasks you may be shuffling.

So the point is made, and everybody agrees that we need more focus and less context switching. And then we go back to our real jobs and get pulled in 10 different directions at once. It’s madness!

So why aren’t many of us willing to do something about it?

I spoke in one of my previous blog posts, ‘The Agile Coach on Courage’ about how standing up and telling your boss that you’re overwhelmed is hard, but necessary. It takes guts. Sometimes you’re being asked to be a member of several project teams at once. Other times, you’re being yanked off an active project (with little to no notice) to work on a pet project for a C-level executive. Telling your boss the consequences of such actions is hard to do, but necessary. And if they’re a good boss, they’ll actively listen to you, empathize, and try to remove any impediments that stand in the way of you getting work done productively and of the highest quality. True servant leadership.

But in order for them to help, you must let them know that this is disrupting not only your productivity, but the rhythm of the team as well.

Scrum Masters, listen up because this is on you as well. One of your major functions is to protect the team. So educate the Departmental Managers on the evils of context switching and multi-tasking. Press the issue tactfully. And if you don’t have enough people to get the work done, raise it as an impediment. Make it visible. Let it drive a discussion around the scope of the Product Backlog, the Release Backlog, or dates. Our velocity is what it is. You want to increase it? Adding more team members oftentimes won’t do it. In fact, it can even decrease velocity in the short term. So be careful of this tactic if you’re running up against a tight deadline. Let it be known that our team works at a sustainable pace. Yes, we can work longer hours from time to time when it’s really needed, but don’t let it become the norm and burn folks out. One of the telltale signs of this occuring is a spike in the number of bugs introduced, a simple metric to keep visible and discuss in your team retrospectives.

I’d like to hear your thoughts on this topic. How do you deal with context switching/multi-tasking?

Latest News on DOD Goes Agile

Scrum Log Jeff Sutherland -

Since I briefed the Coordinating Task Force at the Pentagon on how to report back to the Congress on progess, we've talked a lot about how the US Department of Defense (DoD) is going Agile. We've also shared some ideas on how to do it from SEI. Here is some real concrete guidance about how to do it from the DoD.
We've also been corresponding with four-star General Barry McCaffrey, my former classmate at West Point. He was very clear in his comments on our new book, Scrum: The Art of Doing Twice the Work in Half the Time.
“Scrum is mandatory reading for any leader, whether they’re leading troops on the battlefield or in the marketplace. The challenges of today’s world don’t permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.”
In the process of writing our online course Agile Defense we read with great interest the Interim DoD Instruction 5000.02. This document shows at least one way the DoD is thinking about doing, Agile development in software. 
Here are their two models of software acquisition. The first reflects a certain amount of waterfall thinking:

"Figure 4 is a model of a program that is dominated by the need to develop a complex, usually defense unique, software program that will not be deployed until several software builds have been completed. The central feature of this model is the planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds."



Here's a new, more Agile model of deployment:

"This model is distinguished from the previous model by the rapid delivery of capability through several limited fieldings in lieu of single Milestones B and C and a single full deployment. Each limited fielding results from a specific build, and provides the user with mature and tested sub-elements of the overall capability. Several builds and fieldings will typically be necessary to satisfy approved requirements for an increment of capability. The identification and development of technical solutions necessary for follow-on capabilities have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly."

The new model moves the DOD closer to the second value in the Agile Manifesto - working product over comprehensive documentation. They may not meet the Agile Manifesto principle of delivering product increments in a few weeks to a few months. Yet it is a definite step forward.

At the Pentagon I emphasized that DOD purchasing should require "Change for Free" in all their contracts as it could save them hundreds of billions of dollar a year. The F-35 contract alone is $143B dollars over budget mainly due to software testing!

Sign up for our online course next Wednesday from 11-12 for more on how Scrum, Agile, and the military work together.




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

The Rules for Writing Maintainable Code

Agile Connection -

We've all been burned working with software code that, if not designed for long-term maintainability, results in expensive support over a product's lifetime. Kaushal explores three approaches that provide guidelines to ensure that software is designed with maintainability in mind. If you're a software developer, read this!

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 -

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

Where:
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:
http://www.eventbrite.com/e/actionclub-business-mastery-program-tickets-10908602925?aff=rss

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


A Healthy Daily Scrum

Scrum Alliance -

During the transition of a company from the traditional method to Scrum, we faced a lot of problems in changing the culture and mind-set of the development team, due to their long-term dependence on command and control as used in the traditional way. The symptoms of this problem were clear in their attitude during meetings. . . .

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.

Pages

Subscribe to - Agile Scrum Kanban Coaching Training Phoenix AZ aggregator