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.
Implementing this principle will reduce the work to the bare minimum and lets the team focus on the simplest possible solution for creating the same business value. You have to ask yourself with everything you do “is this really necessary?”. This is a completely new way of thinking for teams that are not used working in an agile environment. Traditionally analysts are used to over-specify their requirements, designers are used to over-design their technical designs, developers are used to over-develop their code and application maintenance are used to over-specify the standards and requirements of the infrastructure. This creates a complex project and a product that is hard to implement. When finalizing the requirements phase in this traditional approach, all stakeholders are committed to their standards and requirements and find it difficult to simplify (or let go) things.
The main advantages of simplification are speed and reduced complexity. You can delivery business value faster and the delivered product is less complex (e.g., less maintenance costs). Every line of code you have to maintain and is a possibility for an error/bug. Producing less code will create less possibility for errors. Simple code means less complexity and less complex testing.
This principle applies not only to technical things, but also in process and communication. Start with simple things and improve/automate them when you are sure they are useful and add value. So just use a whiteboard instead of Visio for drawing images (you can add a photo of the whiteboard to the documentation). Start with using yellow sticky notes for requirements management instead of a state of the art requirements management system.
What do we have to keep it simple?
Coding:
Speed (time to market) is the most important factor for the success of new features. Most features that form a competitive advantage are easy to copy. So with a quick time to market you are flexible and able to react quickly on changes in the environment (market) and always keep one pace ahead of your competition. The fastest way to gain speed and flexibility is to maximize the work not done for the same value. Less work is less time spent on coding. Less work also means less to be designed, tested, documented, deployed and maintained. Less code means less cause for bugs, misinterpretation and errors. A lot of complex code means a lot of complex maintenance.
Architecture:
Minimizing the work done applies also on the overall technical solution. For developers and architects it is tempting to introduce components that are generic and create a technical good (or even “beautiful”) architecture. Implementing these generic components will often cost a lot of work and make the structure complex, hard to explain to other developers, complex to document and to maintain. When the same goal can be reached with a simple structure that is easy to explain (but is not so generic and beautiful) you have gained the advantage of fast implementation, easy documentation and easy transfer to maintenance.
Testing:
When you create unit-tests for your system you have to limit these tests to the unit of code itself. The unit-tests will be executed many times and therefore must be simple and fast (low execution time). These simple tests keep the code maintainable and flexible. When you refractor bits of the code you only have to change a minimal stet of test that are involved in the refactoring. Complex tests that span a lot of classes or involve simulation of a large part of a complex GUI are hard to create, not easy to change and even harder to maintain.
Automation:
Maximizing work not also means reducing the amount of repetitive manual work to zero. In regression testing this is a big saver. Big systems with short release cycles cannot permit long manual test runs. These tests must be automated and executed automatically. This will make the team fast and produce more value in less time. Creating scripts for automatic testing, deployment and archiving artifacts will make the team run on an constant pace and prevent stressful weekend-long testing and deployment sessions.
Standards:
Finally simplicity is applying and adapting to standards. When in doubt and you have to choose, go for the most common and simplest standard that is available for your problem. These standards are proven, easy to understand and to explain to other developers, there is a lot of knowledge available and in most cases there is a large community with professionals that can help when you have questions about the standard.
Conclusion:
At first sight simplicity will only have an effect on reduced work to create things. But simplicity has a secondary effect: Simple things are easy to understand, explain, debug and maintain. So apart from the obvious advantage of reduced production time the simplicity will also have a positive effect on the costs of maintenance, support and debugging.
You can gain simplicity by applying the rule of work not done. When something takes a lot of work to produce (or repeat) they are probably not simple (and therefore costly). Make use of automation to keep things simple and repeatable.
Keep it simple and you will learn that simple is not stupid.
Other posts about the AGILE Principles (soon to come):
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Hello,
Reading your blog makes me feel much more excited to try your using agile project management I always heard that from my friends to easily manage the projects, they try to recommend me this site Taskboard Demo and I like it, so did you try that agile? I think it’s great
Hello,
Currently it seems to be a hype to develop agile;
Nothing against agile behavior in a project.
Bus as projects – many of tehm – lack in clear worklow and responsibility
the agile approach seems to be it to hide weak project leading skills;
so let us be agile – not to ducument to much before doing the first step;
but let us be agile enough to raise hands when the agile appraoch
does not work;
/Karl