And when it comes to new technologies, I love to learn the latest about Amazon’s latest Web Service or new Productivity App for my iPhone.
At work or at home, the latest alert or e-mail appeals to me like water calls a thirsty hiker.
In the modern age of ubiquitous distractions, one of the greatest gifts we can give ourselves is focus. Focus is the unsung hero of so many successful people and successful endeavors.
Thomas Edison is a preeminent example of someone who was focused and persistent. His single-minded search for a sustainable burning ember contains the recipe of success.
In the age of environmentally induced ADHD, we are especially in need of any and all mechanisms, systems, tips, or tricks to help keep us on task.
Enter the time box
When you travel to the airport to get a flight, you have a limited time in which to check-in, get through security and board the plane.The time constraint motivates good behaviors such as planning and focus. You might pack the night before and consider the traffic conditions as you plan your departure time. On the morning of your departure, you won't likely be distracted enough to pick up a book and read a few chapters or look over your family budget or commit yourself to buy a brand new travel bag.
Scrum and other Agile systems typically utilize a 2-4 week time box (sprint) to enhance focus in teams. Institutionalizing a fix period to create and deliver working software applications is just like getting to the airport on time, you eliminate distractions and make sure you have a good plan. However, practicing good time box discipline is hard because it can feel arbitrary. It’s less arbitrary when you consider the business side of agile:
Deliver customer value (a working product or feature) at the end of each sprint and revenue can be earned immediately for the company.
A sure fire way to how to torpedo agile -- treat your time box like it’s a ‘hopefully we make it box’. You’ll lose a lot of the power of scrum
because getting things working and deployed to customers on a regular schedule core to agile development.
Here are some tips to help keep teams focused on the time box:
1. Don’t cave to the ‘multi-sprint’ development paradigm
Sometimes the magnitude of a new feature or product looks like it’s impossible to break down into component parts or perhaps the component parts are understood, but they seem too large for a 2 week development cycle.At the start of a project it’s very difficult to create a simple working product in 2 weeks especially if the end product appears to have significant complexity. But it’s not impossible and it’s actually prudent to break it down.
If you are a scrum master
or product owner 
or developer, be diligent and painstakingly help the team decompose problems into smaller nuggets that have value and can be created in 2-4 weeks. These processes can be tough to comprehend for teams new to agile, but it's worth the pain and effort to create a discipline of delivering value every sprint.
Decomposition does not attempt to throw away the grand vision of a larger and more comprehensive application, but to FOCUS on composing working building blocks every step of the way.
2. Decouple ‘multiple features in one story’
In some cases a single customer request that has multiple features packed inside. At first these features look like a collective package that can't be broken. But if you listen carefully and ask for specific examples about the use case, you can assist in breaking out multiple stories that represent individual items with stand-alone value.This helps to FOCUS the discussion and prioritization efforts by examining a pond rather than an ocean of ideas.
3. Dig deeper in developing the definition of done and possibly get down to the details in task planning
It’s easy to get off track or even falter in planning and executing a sprint if there is ambiguity about what the team is doing. For most experienced teams they know that each story requires a Definition of Done (DoD).The DoD for a story can be written literally as, "This story is done when...such and such happens." For an online shopping cart a DoD might read, "This story is done when the user can select an item from the online store and then it shows up in the shopping cart when the shopping cart icon is clicked." Other Dod alternatives include a bulleted list, or a series of well written tests that must pass.
Team sometime include process related criteria as a boiler plate in the DoD such as, "Must be code reviewed. Must pass a sanity test. Must be delivered to specific servers or development environment."
The next step beyond the DoD is to get more detailed when it comes to recording each task associated with the story. A team will have more confidence in achieving sprint goals when they have clarity about how things are decomposed on a task level.
Writing a DoD enables the team to FOCUS on the details of how a story will be created in real life and this results in a better plan for sprint execution.
4. Don’t settle for progress when you can have completion
Progress is good, but not profit-making. Doneness is great and profitable. If the team is not reaching done, then hold a retrospective
. Don't be generic about your retrospective
. It should be FOCUSED on one thing…getting to Done. Here’s another article where I describe a how-to plan for a retrospective, “Learn from the Past to Make the Future Better.”What do you think your biggest issue is when it comes to completing all the items in a sprint?
Thanks in advance for any comments.
http://www.steveteske.com