July 16th, 2010
To ensure that the project is making progress, each iteration is forced to produce something tangible: a “release.” This release can be:
- A prototype that is used to demonstrate some specific capability
- An “internal” release that is used to elicit feedback and that serves as the basis for further development and testing
- An “external” release that is shipped to customers in some form
The following is our definition of release:
Release: A stable and executable version of a system.
The production of something executable during each and every iteration is so important to the iterative approach that some people even go as far as to assert that “The goal of an iteration is an iteration release: a stable, integrated and tested, partially complete system.” Read the rest of this entry »
No Comments » |
Process Improvement |
Permalink
Posted by Kurt Bittner
June 29th, 2010
Each iteration is unique. It involves undertaking a unique set of activities to produce a unique version of the product that objectively demonstrates that the iteration objectives have been met.
Because of this uniqueness, each iteration requires its own iteration plan. The iteration plan contains the details of all the activities that the team is required to do to meet the iteration objectives. The amount and style of activity-level planning required for a project is dependent on many factors including the project risk, team size, experience levels, and the manager’s own preferred management style.
For some projects, an informal plan describing the goals to be achieved and listing the tasks to be undertaken is sufficient; you can leave the scheduling and allocation of the activities to the development team. Other projects require more comprehensive plans that describe the activities and their allocation in greater detail to work out the dependencies between the tasks to be performed by the various team members. Read the rest of this entry »
No Comments » |
Process Improvement |
Permalink
Posted by Kurt Bittner
May 28th, 2010

Iteration: A self-contained mini-project, with a well-defined outcome: a stable, integrated, and tested “release”. Let’s look at the three aspects of this definition in more detail.
A software development project produces a new release of a software product by transforming a set of users’ requirements into a new or changed software product. With an iterative and incremental approach, this process is completed little by little, step by step, by splitting the overall project into several mini-projects, each of which is called an iteration.
From the perspective of the development team, each iteration can be considered to be a self-contained
project. This approach is very powerful because it enables the development team members to focus on meeting their immediate objectives and ensures that the results generated are frequently and objectively measured. The management team needs to ensure that the iteration objectives form
a credible part of the larger overall project.
The management team needs to reinforce this way of working by ensuring that each iteration has the following:
Read the rest of this entry »
No Comments » |
Agile Development, Iterative Development, Process Improvement, Requirements Management |
Permalink
Posted by Kurt Bittner
May 13th, 2010
The kernel Alphas are the core, key, critical, central, essential conceptual entities that we need to manage and progress in a controlled way in order to ensure a successful outcome for our project. But, like all concepts, they have the distinct disadvantage of being invisible. A project manager is convinced that his project is important and that managing its progression to a successful conclusion is critical. But if, as an outside assessor, I were to say “bring me this project of which you speak so that I may gaze upon it and assess its status” he would be stumped. He can show me plans, people, documents, but he can’t show me “the project”. These key concepts are the elephants in the room that no one can see because … well , because they are invisible. To be useful, they need to be made visible and real, so normal people can interact with them.
Read the rest of this entry »
No Comments » |
Agile Development, Essential Practices, Process Improvement |
Permalink
Posted by Roly Stimson
April 8th, 2010
I have met hundreds of organizations that are trying to improve their way-of-working. What I have found most interesting is that the vast majority of these organizations are looking for the solution outside of the company. They are either benchmarking with other similar organizations or running after the latest fashion in the industry. However the perceived benefits are not always there and the answer is usually much closer than they know.
Good industry standards are one thing, but many things that are good for a specific company are not necessarily transferable to another company with another background and culture.
In reality many solutions can be found inside the company. There are top-performers, top performing teams and projects in all companies and if we could repeat the good behavior from those individuals and teams, the organization could improve tremendously. However we need a structured way to capture that behavior so that it could be easily understood, distributed and reused; this is where using Practices makes perfect sense. Practices is a way to effectively describe the Essentials of Things to do, Things to Produce and the Competencies needed for a specific area of concern.
What good practices do you have in “your belly button”?
No Comments » |
Essential Practices, Process Improvement |
Permalink
Posted by Pernilla Ramslov
March 23rd, 2010
In my last three blogs, I discussed how we can close the gap between the business and IT. I summed up the way forward with the advice to stop thinking about the business as the customer and IT as the provider. Instead, let them work together in teams (similar to members of a soccer team), responsible directly to management.
It will not be an easy journey, but here are some steps along the way:
Read the rest of this entry »
3 Comments |
Iterative Development, Ivarblog, Process Improvement, Requirements Management, Training |
Permalink
Posted by Ivar Jacobson
February 2nd, 2010
I was celebrating my birthday in Japan with a team I mentored. The manager was present and he asked me politely what my birthday wish was. I said I wanted to slim down without thinking much. It was something I wanted, but had not been succcessful. But through the weeks following that, by being conscious about calorie intake and output, spreading my food intake, reducing portions, adding some exercises, my weight reduced dramatically. I call it "dramatically" because I never lost that much. Within about a month, I lost 8 kilograms, and then another 6 the next month and another 6 on the third. I had to buy a new pair of pants twice. There were no dieting pills, no starving myself, no gym, but just some self-control, having daily stand-up meetings with my weighing scale and food calorie labels and of course some discipline and commitment with encouragement from weight logs. Read the rest of this entry »
No Comments » |
Agile Development, Process Improvement |
Permalink
Posted by Pan-Wei Ng
January 28th, 2010
We in the software development industry face a seemingly intractable problem. We have learnt the lesson that prescriptive process is a bad thing. Process bureaucrats sitting in ivory method towers, telling highly-skilled professionals how to do their job and setting the process police on them if they don’t follow their instructions to the letter, can (unsurprisingly) be really quite damaging. It disempowers the development team and engrains apathetic attitudes along the lines of “When we inevitably under-deliver, it will not be our fault, but the fault of these ludicrous process hoops that we are forced to jump through, instead of being able to focus on writing great software”. The agile revolution was software engineering’s way of learning this lesson, and the agile manifesto pledge to value “people over process” and “software over documentation” has got to be right. But (… there was always a “but” coming …), we are already finding that the opposite extreme of little or no explicit process isn’t going to cut it either, because it leaves too many problems unsolved, such as: Read the rest of this entry »
2 Comments |
Process Improvement, Requirements Management |
Permalink
Posted by Roly Stimson