Weblog for the AMIS Technology corner
Posts tagged Principles
Agile software development, the principles. Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
Dec 14th
This is the eleventh of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
For a long time the engineering expertise (and also software engineering) was based upon the condition that you worked with specialists. These specialists emerged from the principle of division of labour and made it possible for these specialists to focus their attention on their specialism and create the best solution within their field of expertise. The Interaction designer designed a user interface, the architect created a global systems model, developers created code and infrastructure specialists created the necessary environment to run the application on.
Everyone was specialized and delivered the best solution within their capabilities. However when all these components where put together, noting worked. It is an illusion that specialists can design and foresee everything beforehand.
Within agile projects the solution is to use a self organizing team to perform these tasks. This team may consist of specialist, but this is not a requirement. The requirement of this team is that they work together and self-organize all aspects of the systems to be delivered. This team is permitted to make errors and invent their solutions, provided that they deliver and evaluate frequently (retrospective) and learn from their successes (and errors).
Agile software development, the principles. Principle 10: Simplicity–the art of maximizing the amount of work not done–is essential
Aug 3rd
This is the tenth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 10: Simplicity–the art of maximizing the amount of work not done–is essential.
The KISS rule (Keep it stupid and simple) applies here. Simple things are easy to understand, and straightforward to implement. Simple things do not cost a lot of time (or money) to implement and are therefore also easy (painless) to revert.
The middle part of this principle “maximizing the amount of work not done” is harder. When implementing agility in an organization this is the cause of discussion. Maximizing the work not done implies that the agile method will skip some processes, code and steps that where necessary in the traditional way of delivering software. This is where agile is linked with Lean. Lean focuses on reducing waste and creating a lean process. Work not done (that was planned to do) with the same end-value, can be classified as waste. In a discussion about work not done, you ask the person asking the question to specify the added business value of the work relative to other tasks. When the added value is not clear this is probably waste. Here you have to discuss the added value of intensive review sessions, bureaucratic procedures, complex frameworks and other corporate rules we meet every day.
(Dutch) AMIS kennissessie Scrum
Feb 27th
Datum: dinsdag 3 maart 2009
Tijd: 16:30 tot 21:00, incl. diner
Locatie: AMIS, Edisonbaan 15 in Nieuwegein
Doelgroep: Deze sessie is interessant voor zowel developers, projectmanagers, consultants als sales medewerkers.
Coördinator: Robbrecht van Amerongen
Scrum, Just enough, just in time…
Scrum is een methodiek die ons in staat stelt om snel kwalitatief hoogwaardige software op te leveren; er wordt ontwikkeld en opgeleverd wat volgens de inzichten van vandaag nodig is (in plaats van wat maanden geleden eens is bedacht).
Read the rest of this entry »
Agile software development, the principles. Principle 9 : Continuous attention to technical excellence and good design enhances agility
Dec 28th
This is the ninth of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 9: Continuous attention to technical excellence and good design enhances agility.
The first time I looked at this principle I thought: “How is this possible”. Agility focuses on quickly delivering working software (reading: “Quick and dirty”). I experienced this is not true. Attention to technical excellence is making the agile process working better. Technical excellence can make the development process more flexible. In this context I would like to point out that there is a difference between technical excellence / good design compared to complex design and technical complexity. How many developers, designers and architects (the ivory tower / PowerPoint architects) cannot resist creating complex designs, patterns and code with no other purpose than to show off their technical superiority? How many projects have stranded in complex designs and abstract meta-models without creating any business value? These projects are good to be displayed in the Museum Of Modern Software Development but completely useless in the real world.
Smart technology and smart design
Every developer, architect and designer must work with principles of smart design in their minds. In my opinion there are only two principles: 1) the concept must work and 2) other team members understand and are able apply the principle.
Smart technology and good design has its greatest advantage when it is used for the benefit of the whole application and the whole team. Not just for sub-optimal improvements for a single function or a single developer. Good excellent technology and good design has to make coding easy and the application modular, more flexible and adaptable. By using the right frameworks and supporting tools you are able to deliver higher quality software much faster than you where used to. In practice this means using frameworks for common tasks like authorization, persistence and navigation and tools for building, releasing and deploying your application.
In fact all tasks, that are labor intensive and demand a lot of concentration and focus, are likely candidates to be implemented via frameworks and tools.
Agile software development, the principles. Principle 7: Working software is the primary measure of progress.
Jul 1st
This is the seventh of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 7: Working software is the primary measure of progress.
How do you measure progress in agile projects? The required functionality is not fixed and the planning of construction and delivery of these requirements is done by the team, in a very late stage. This is something traditional project managers have a hard time to cope with. They think it is impossible to control a project, with an unclear outcome and a planning, that is based upon a work backlog and the duration of a sprint (iteration).
The fundamental measure of progress is measuring things that are finished. Software (in our case) is finished when it is successfully tested and delivered. Software progress is not “80% done coding”. Software is finished when it is tested and accepted by the (key) end-user. By adding the end-user to the project team, he/she will be motivated to test and accept the delivered artefact quickly. Read the rest of this entry »
Agile software development, the principles. Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Aug 24th
This is the second of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story.
Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
This is one of the marketing / sales pitfalls of agile software development. What sales executive like to tell the customer is “Our agile process is designed in such a manner that we can incorporate changes during the whole development phase, even in the end”. This is nice customer expectation management (understatement). What the customer understands form this promise is that this project is able to incorporate all changes in requirements even up to a few day’s (or even hours) before going life.
Agile software development, the principles. Principle 1: Deliver valuable software
Jun 8th
This is the first of 12 posts about the principles of agile software development.
Purpose of this, and the upcoming 11 posts, is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering.
Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.
The question is: is this going to work in practice or is this only based on a nice marketing and sales story?.
Principle 1: Satisfy the customer through early and continuous delivery of valuable software.
The discussion here is of course "what is valuable software?".
Opinions differ between stakeholders of the project. From a developer perspective valuable software is nice designed with all OO principles of encapsulation, inheritance and abstraction. From the end-user perspective valuable software is a rich, customizable user interface and loads and loads of features that make the daily work easier. The support department sees valuable software as easy to install, configure, manage and cost effective in maintenance. The business owner just wants an effective TCO value in relation to the business value. To get an answer to this question you have to get back to the business case of the project. The business case sets the GOALS of the project against to the costs of creating the deliverables to reach the goal. The Software is just one (in many cases the most important) of the deliverables of the project and the customer uses the deliverable to reach the goal.
