While it may look like Agile teams all work in big empty “common rooms”, the truth is that people need more than that. Elements like light, air, traffic flow, noise, refreshments and comfort are not negligible: high productivity teams still consist of people, not robots, and these hard working people can be enabled or discouraged by the spaces in which they work.
Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.
by Paul Klipp
For a decade now, agile processes, of which the best known is probably eXtreme Programming, have been gaining wide acceptance among developers, but many customers are still in the dark. Agile sounds good, but what does it mean? This is a quick and dirty preview of what you can expect when you choose an agile process.
My first iteration using Agile Work for my business development has come to a close. Here is what I did for a “demo” and retrospective.
A reader has asked:
I was wondering if you have any white papers or best practices on how to implement the agile methodology in a “product†company where we do more implementation of our product , not really new development. We have some development phases where we customize our product but we don’t necessarily do ‘pure software development†like Greenfield projects….
Here are my thoughts…
In Scrum, there is some confusion around the various types of estimation that are done. Product Backlog Items are estimated and Sprint Backlog Tasks are also estimated. These two estimates, despite some similarities, are used for very different purposes.
Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.
Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in “From the ‘You Call this Agile’ Department“:
Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.
Okay… I’ll bite.
I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I’m starting to see and hear some of the results of this training. There are a couple specific “smells” that I have become aware of.
I was running late for a meeting. Frustrated over being late, the meeting itself that looked like a waste of time, and overall number of meetings we have, I got an enlightment:
Meetings are a penalty for the lack of effective [face to face] communication.
Meetings are overhead. Trash. Wasted time, multiplied by the number of participants. They grow in length and numbers and the process becomes Meeting Driven Development.
But in a real world software organization we do have meetings, and no chance to eliminate them in any foreseeable future. The best we can is keep them under control.
A prioritized list of work items is a key artifact of any Agile development process. Take a SCRUM Project Backlog or eXtreme Programming User Stories as examples. Armed with such lists, the development team will be working on the most important tasks at any given time.
The problem, however, is that assigning priorities to real tasks on a real projects doesn’t follow a simple recipe. The act of prioritizing is the art of prioritizing. And as with any art, there are always tips and tricks. I will share a few from my experience.
Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is “right” is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.
I’ve been researching the requirements and variations on the Product Owner Role for a client that I am assisting. Here is a small collection of links and notes.
Updated (Originally posted Nov. 18, 2005).
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.