This link has been bookmarked by 177 people . It was first bookmarked on 02 Jul 2006, by Russ.
-
06 Sep 16
-
12 Aug 16
Pablo Fernández MenaFowler on Agile, 2000 - present. Yeah, you should read it. https://t.co/Pw5S4P7sU6
-
28 Jun 15
-
-
01 Jun 15
-
15 Jan 15
-
30 Oct 14
-
Separation of Design and Construction
-
So what we see here are two fundamentally different activities. Design which is difficult to predict and requires expensive and creative people, and construction which is easier to predict.
-
In civil engineering construction is much bigger in both cost and time than design and planning.
-
If we can make all the significant decisions using the UML, we can build a construction plan and then hand these designs off to coders as a construction activity.
-
But here lies the crucial question. Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?
-
People who work on methodology are not very good at identifying boundary conditions: the places where the methodology passes from appropriate to inappropriate.
-
There's a strong temptation to do that. Predictability is a very desirable property. However if you believe you can be predictable when you can't, it leads to situations where people build a plan early on, then don't properly handle the situation where the plan falls apart. You see the plan and reality slowly drifting apart. For a long time you can pretend that the plan is still valid. But at some point the drift becomes too much and the plan falls apart. Usually the fall is painful.
-
-
08 Oct 14
-
07 Jun 14
-
22 May 14
Caroline WoodThe most important, and still difficult part is to know accurately where we are. We need an honest feedback mechanism which can accurately tell us what the situation is at frequent intervals.
-
"the problem with this project is that the requirements are always changing".
-
It's very difficult to see what value a software feature has until you use it for real.
-
The most important, and still difficult part is to know accurately where we are. We need an honest feedback mechanism which can accurately tell us what the situation is at frequent intervals.
-
The point of this is that there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project.
-
both in terms of bugs and in terms of misunderstood requirements.
-
The tendency, however, is to make each iteration as short as you can get away with. This provides more frequent feedback, so you know where you are more often.
-
The team needs to be effective both in the quality of the individuals, and in the way the team blends together.
-
not just does adaptivity require a strong team, most good developers prefer an adaptive process.
-
If you expect all your developers to be plug-compatible programming units, you don't try to treat them as individuals. This lowers morale (and productivity). The good people look for a better place to be, and you end up with what you desire: plug-compatible programming units.
-
When you want to hire and retain good people, you have to recognize that they are competent professionals. As such they are the best people to decide how to conduct their technical work.
-
they need very close contact with business expertise.
-
-
14 Apr 14
-
18 Feb 14
-
23 Oct 13
-
19 May 13
-
20 Mar 13
-
15 Nov 12
-
05 Nov 12
-
09 Aug 12
-
28 May 12
-
I wrote it, like most of my essays, as part of trying to understand the topic.
-
-
13 May 12
Jasmen DorianTypes of agile programming
Pros and cons of agile
Resources for agile approach
Process theory -
07 Apr 12
-
23 Feb 12
-
27 Jan 12
-
17 Nov 11
-
02 Nov 11
-
27 Sep 11
-
10 Aug 11
-
21 Jul 11
-
16 Jul 11
-
25 Jun 11
-
16 Jun 11
-
In the title, [of his article] I refer to people as "components". That is how people are treated in the process / methodology design literature. The mistake in this approach is that "people" are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts of unplanned project trajectories we so often see.
-
One of the open questions about agile methods is where the boundary conditions lie. One of the problems with any new technique is that you aren't really aware of where the boundary conditions until you cross over them and fail.
-
-
28 May 11
-
13 May 11
-
08 May 11
-
You end up being in the situation where you may have some desire for a sun roof on your car, but the salesman can't tell you if it adds $10 to the cost of the car, or $10,000. Without much idea of the cost, how can you figure out whether you want to pay for that sunroof?
-
to frequently produce working versions of the final system that have a subset of the required features
-
Documents can hide all sorts of flaws
-
the management aspects of software development
-
provide a common set of practices for teams to choose from for an individual project
-
Use Case Driven
-
driven through user-visible features
-
architecture centric
-
the desire of people to market the RUP as the single process led to a result where people can do just about anything and call it RUP
-
-
11 Apr 11
-
ften characterized by
-
software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This actually works pretty well as the system is small, but as the system grows it becomes increasingly difficult to add new features to the system
-
no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work
-
XP begins with five values (Communication, Feedback, Simplicity, Courage, and Respect)
-
Values without practices are hard to apply and can be applied in so many ways that it's hard to know where to start
-
is its strong emphasis on testing
-
One of the most striking
-
-
29 Mar 11
-
04 Jan 11
-
27 Dec 10
Sahana Chattopadhyay"One of the big dangers is to pretend that you can follow a predictable process when you can't. People who work on methodology are not very good at identifying boundary conditions: the places where the methodology passes from appropriate in inappropriate. Most methodologists want their methodologies to be usable by everyone, so they don't understand nor publicize their boundary conditions. This leads to people using a methodology in the wrong circumstances, such as using a predictable methodology in a unpredictable situation."
-
16 Dec 10
-
Agile methodologies developed as a reaction to these methodologies. For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the engineering methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff.
-
- Agile methods are adaptive rather than predictive. Engineering methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
- Agile methods are people-oriented rather than process-oriented. The goal of engineering methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work.
-
Since the drawings specify the pieces and how they need to be put together, they act as the foundation for a detailed construction plan. Such a plan can figure out the tasks that need to be done and what dependencies exist between these tasks. This allows for a reasonably predictable schedule and budget for construction. It also says in detail how the people doing the construction work should do their work. This allows the construction to be less skilled intellectually, although they are often very skilled manually.
So what we see here are two fundamentally different activities. Design which is difficult to predict and requires expensive and creative people, and construction which is easier to predict. Once we have the design, we can plan the construction. Once we have the plan for the construction, we can then deal with construction in a much more predictable way. In civil engineering construction is much bigger in both cost and time than design and planning.
So the approach for software engineering methodologies looks like this: we want a predictable schedule that can use people with lower skills. To do this we must separate design from construction. Therefore we need to figure out how to do the design for software so that the construction can be straightforward once the planning is done.
-
So what form does this plan take? For many, this is the role of design notations such as the UML. If we can make all the significant decisions using the UML, we can build a construction plan and then hand these designs off to coders as a construction activity.
But here lies the crucial question. Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?
All of this brings a few questions to mind. The first is the matter of how difficult it is to get a UML-like design into a state that it can be handed over to programmers. The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing. The models that civil engineers use are based on many years of practice that are enshrined in engineering codes. Furthermore the key issues, such as the way forces play in the design, are amenable to mathematical analysis. The only checking we can do of UML-like diagrams is peer review. While this is helpful it leads to errors in the design that are often only uncovered during coding and testing. Even skilled designers, such as I consider myself to be, are often surprised when we turn such a design into software.
-
Another issue is that of comparative cost. When you build a bridge, the cost of the design effort is about 10% of the job, with the rest being construction. In software the amount of time spent in coding is much, much less McConnell suggests that for a large project, only 15% of the project is code and unit test, an almost perfect reversal of the bridge building ratios. Even if you lump in all testing as part of construction, then design is still 50% of the work. This raises an important question about the nature of design in software compared to its role in other branches of engineering.
-
- In software: construction is so cheap as to be free
- In software all the effort is design, and thus requires creative and talented people
- Creative processes are not easily planned, and so predictability may well be an impossible target.
- We should be very wary of the traditional engineering metaphor for building software. It's a different kind of activity and requires a different process
This thinking leads to some important conclusions:
-
But even if you could settle all that and really could get an accurate and stable set of requirements you're probably still doomed. In today's economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading.
-
Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.
-
There are projects out there that are space shuttles. However I don't think much business software fits into that category. For this you need a different kind of process.
-
There's a strong temptation to do that. Predictability is a very desirable property. However if you believe you can be predictable when you can't, it leads to situations where people build a plan early on, then don't properly handle the situation where the plan falls apart. You see the plan and reality slowly drifting apart. For a long time you can pretend that the plan is still valid. But at some point the drift becomes too much and the plan falls apart. Usually the fall is painful.
-
hard blow. It means that many of the models for controlling projects, many of the models for the whole customer relationship, just aren't true any more. The benefits of predictability are so great, it's difficult
-
However letting go of predictability doesn't mean you have to revert to uncontrollable chaos. Instead you need a process that can give you control over an unpredictability. That's what adaptivity is all about.
-
that have a subset of the required features. These working systems are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.
-
The point of this is that there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project. Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements.
-
This kind of adaptive process requires a different kind of relationship with a customer than the ones that are often considered, particularly when development is done by a separate firm. When you hire a separate firm to do software development, most customers would prefer a fixed-price contract. Tell the developers what they want, ask for bids, accept a bid, and then the onus is on the development organization to build the software.
-
This doesn't mean that you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.
-
In an adaptive process the customer has much finer-grained control over the software development process. At every iteration they get both to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers, a true business partnership. This level of engagement is not for every customer organization, nor for every software developer; but it's essential to make an adaptive process work properly.
-
All this yields a number of advantages for the customer. For a start they get much more responsive software development. A usable, although minimal, system can go into production early on. The customer can then change its capabilities according to changes in the business, and also from learning from how the system is used in reality.
-
Every bit as important as this is greater visibility into the true state of the project. The problem with predictive processes is that project quality is measured by conformance to plan. This makes it difficult for people to signal when reality and the plan diverge. The common result is a big slip in the schedule late in the project. In an agile project there is a constant reworking of the plan with every iteration. If bad news is lurking it tends to come earlier, when there is still time to do something about it. Indeed this risk control is a key advantage of iterative development.
-
Mary Poppendieck summed up this difference in viewpoint best for me with her phrase "A late change in requirements is a competitive advantage"
-
I think most people have noticed that it's very difficult for business people to really understand what they need from software in the beginning. Often we see that people learn during the process what elements are valuable and which ones aren't. Often the most valuable features aren't at all obvious until customer have had a chance to play with the software. Agile methods seek to take advantage of this, encouraging business people to learn about their needs as the system gets built, and to build the system in such a way that changes can be incorporated quickly.
-
All this has an important bearing what constitutes a successful project. A predictive project is often measured by how well it met its plan. A project that's on-time and on-cost is considered to be a success. This measurement is nonsense to an agile environment. For agilists the question is business value - did the customer get software that's more valuable to them than the cost put into it. A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.
-
When you want to hire and retain good people, you have to recognize that they are competent professionals. As such they are the best people to decide how to conduct their technical work. The Taylorist notion of a separate planning department that decides how to do things only works if the planners understand how to do the job better than those doing it. If you have bright, motivated people doing the job then this does not hold.
-
Another point is that the developers must be able to make all technical decisions. XP gets to the heart of this where in its planning process it states that only developers may make estimates on how much time it will take to do some work.
-
Such technical leadership is a big shift for many people in management positions. Such an approach requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Notice that I say equal. Management still plays a role, but recognizes the expertise of developers.
-
An important reason for this is the rate of change of technology in our industry. After a few years technical knowledge becomes obsolete. This half life of technical skills is without parallel in any other industry. Even technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.
-
Introducing measured management without good measures leads to its own problems. Robert Austin made an excellent discussion of this. He points out that when measuring performance you have to get all the important factors under measurement. Anything that's missing has the inevitable result that the doers will alter what they do to produce the best measures, even if that clearly reduces the true effectiveness of what they do. This measurement dysfunction is the Achilles heel of measurement-based management
-
The point of all this is that traditional methods have operated under the assumption that measurement-based management is the most efficient way of managing. The agile community recognizes that the characteristics of software development are such that measurement based management leads to very high levels of measurement dysfunction. It's actually more efficient to use a delegatory style of management, which is the kind of approach that is at the center of the agilist viewpoint.
-
But the technical people cannot do the whole process themselves. They need guidance on the business needs. This leads to another important aspect of adaptive processes: they need very close contact with business expertise.
-
Since developers are capable professionals in their own discipline, they need to be able to work as equals with other professionals in other disciplines.
-
So far I've talked about adaptivity in the context of a project adapting its software frequently to meet the changing requirements of its customers. However there's another angle to adaptivity: that of the process changing over time. A project that begins using an adaptive process won't have the same process a year later. Over time, the team will find what works for them, and alter the process to fit.
-
The term 'agile' refers to a philosophy of software development.
-
-
05 Dec 10
-
23 Nov 10
-
19 Nov 10
-
14 Oct 10
-
11 Aug 10
-
26 Jul 10
-
Jack Reeves to suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.
-
- In software: construction is so cheap as to be free
- In software all the effort is design, and thus requires creative and talented people
- Creative processes are not easily planned, and so predictability may well be an impossible target.
- We should be very wary of the traditional engineering metaphor for building software. It's a different kind of activity and requires a different process
This thinking leads to some important conclusions:
-
A fixed price contract requires stable requirements and hence a predictive process
-
-
21 Jul 10
Rémy Sanlaville"In the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landscape. In this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation. "
-
10 May 10
-
Agile methodologies developed as a reaction to these methodologies. For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the engineering methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff.
-
only 15% of the project is code and unit test, an almost perfect reversal of the bridge building ratios. Even if you lump in all testing as part of construction, then design is still 50% of the work.
-
If you cannot get stable requirements you cannot get a predictable plan
-
if you are in a situation that isn't predictable you can't use a predictive methodology
-
how do we control ourselves in an unpredictable world
-
We need an honest feedback mechanism which can accurately tell us what the situation is at frequent intervals.
-
Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements.
-
A fixed price contract requires stable requirements and hence a predictive process.
-
This doesn't mean that you can't fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.
-
A usable, although minimal, system can go into production early on.
-
The problem with predictive processes is that project quality is measured by conformance to plan
-
"A late change in requirements is a competitive advantage"
-
For agilists the question is business value - did the customer get software that's more valuable to them than the cost put into it.
-
very effective team of developers
-
they are the best people to decide how to conduct their technical work
-
Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.
-
when measuring performance you have to get all the important factors under measurement
-
continuous access to business expertise
-
developers professional responsibility is to adapt the process to the task at hand
-
If customers don't collaborate, then you won't see the full advantages of an adaptive process.
-
on several occasions that we've worked with customers who didn't want to collaborate, but changed their mind over the first few months as they begun to understand the agile approach
-
-
28 Apr 10
-
15 Apr 10
-
13 Mar 10
-
04 Feb 10
-
07 Jan 10
-
30 Nov 09
-
16 Nov 09
-
10 Nov 09
-
12 Oct 09
-
I've seen descriptions of RUP usage that range from rigid waterfall with 'analysis iterations' to picture perfect agile.
-
In today's environment, the most common methodology is code and fix. Applying more discipline than chaos will almost certainly help, and the agile approach has the advantage that it is much less of a step than using a heavyweight method
-
If the people involved aren't interested in the kind of intense collaboration that agile working requires, then it's going to be a big struggle to get them to work with it. In particular I think that this means you should never try to impose agile working on a team that doesn't want to try it.
-
-
20 Sep 09
-
04 Sep 09
-
14 May 09
-
06 May 09
-
23 Mar 09
-
10 Mar 09
-
-
23 Jan 09
Mads BødkerIn the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landsca
process software methodology development project reference programming management work scrum rup projectmanagement
-
07 Nov 08
milovandiestIn the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landsca
-
26 Oct 08
-
08 Aug 08
-
08 Jul 08
-
06 Jul 08
-
26 Jun 08
-
24 Jun 08
-
06 Jun 08
-
27 May 08
-
29 Apr 08
-
18 Apr 08
-
08 Apr 08
-
19 Mar 08
-
20 Jan 08
-
09 Jan 07
viniciusjlIn the past few years there's been a blossoming of a new style of software methodology - referred to as agile methods. Alternatively characterized as an antidote to bureaucracy or a license to hack they've stirred up interest all over the software landsca
article toread blog agile methodology development design process for:yoda for:tcristino for:rafaeldff for:mcide67 for:josch for:gnustavo for:exadmax for:eduardo.rosa for:andreyev_br for:andersondesalve
-
07 Jan 07
-
ong test phase after the system is "feature complete"
-
ringing a forceful dose of reality into any project
-
-
03 Jan 07
-
03 Dec 06
-
31 Oct 06
-
25 Oct 06
-
08 Aug 06
-
31 Jul 06
-
02 Jul 06
-
05 Jun 06
-
02 May 06
-
24 Apr 06
-
06 Mar 06
-
22 Jan 06
-
12 Jan 06
-
07 Jan 06
auxonne auxonneIn this essay I explore the reasons for agile methods, focusing not so much on their weight but on their adaptive nature and their people-first orientation.
-
03 Jan 06
-
31 Dec 05
Page Comments
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.