Agile Capability Maturity Model

Agile Capability Maturity Model

After all the differences we have talked about, the question arises. Does it make sense to have a Capability Maturity Model for Agile? How would it be? Let’s analyze the semantics of the words again, but in an Agile context.

What does it means to be capable, in an agile context?

In the CMMI model, Capability was defined as “the inherent ability of a process to produced the planned results. As the capability of a process improves, the process becomes predictable and measurable, the quality of the result product augments and the productivity of the teams too”. Thus, an organization gets more capable when it has defined and implemented a set of processes throughout the organization that enables it to be predictable, measurable, and continuously improving.

Does the word have the same meaning in an agile context? Agility is more like a mindset or culture than a set of processes. Thus, in Agile you are capable when you have the mindset and the organization is capable when it has the mindset. The semantics of the word changes considerably and worst of all, it makes it unmeasurable. How would you measure how much of the mindset the organization has? Nonetheless, and perhaps very subjectively, one can recognize a team/organization that is more Agile than another. You do it because it adheres better to the Agile values (communication, collaboration, technical excellence, etc). Using this subjectivity, perhaps we can define the meaning of capable in an Agile context. One is capable when it has grasped the Agile values, when you are at the Ri level (in the Shu-Ha-Ri scale) or, as some people say, when you ARE agile. 

How do you get more mature?

Using CMMI, you get more mature as you implement the different processes that conform the model throughout the organization, you can measure them and draw conclusions out of the metrics that allows the organization to improve. 

If we follow the definition of capability in an Agile context given above, the definition of maturity falls in the subjective side as well. An organization is more mature when it can communicate better, it can collaborate better, is able to produce its products with the required quality sustainably, etc. 

Senge talks about the intelligent organization. A mature Agile organization is an intelligent organization. It’s an organization where its members are smart agents that collaborate among them to solve problems and improve continuously. Today’s knowledge organization need to mature in this direction.

The Schneider Culture Model

This diagram is taken from The Reengineering Alternative: A plan for making your current culture work, the book by William Schneider. In it, there are 4 cultures. Each has its name, picture and some words that characterized the quadrant.

There are also two axis that indicate where the focus or an organization is:

1. Horizontal: People Oriented (Personal) vs. Company Oriented (Impersonal)
2. Vertical: Reality Oriented (Actuality) vs. Possibility Oriented

And if we map the Agile values and principles to this model...

We can see how Agile mainly falls into the collaboration and cultivation cultures. I believe that the introduction of CMMI in an Agile Culture moves the culture to the “Control” quadrant. Many people believe this is the way to scale agile and therefore it could be argued that CMMI could be a good way to scale Agile. I don’t feel very comfortable with this idea, as I believe that a good maturity framework should allow the organization to mature without losing its values, its heart. In other words, I believe the maturity needs to happen in the collaboration/cultivation quadrant mainly and the competence one. 

Conclusion

A capability maturity framework for Agile needs to redefine the meanings of capability and maturity to suit the context as being capable and mature have very different semantics in the CMMI world and the Agile one. An Agile Capability Maturity Model should make the organization mature towards a collaboration/cultivation culture. The Agile definitions of capable and mature makes introduce a lot of subjectivity. Could we still measure the results?

The secret ingredient.... feedback

A few days ago, I went to a OO course, given by Hernan, a colleague at 10 pines. The course started with the basics: a definition of software. Hernan gave this definition: software is a computable model of a problem domain from reality. Our job as software developers is to interpret that problem domain and construct a computable (executable) model that suits the needs of the users.

Now the question is how you get to that model? I started thinking that sequential approaches (waterfall) take an approach of trying to understand very well the problem domain before starting the construction of the model. The gap is bridged by domain experts that specify thorough-fully the problem domain so that technical people start from there.  The Agile approach, on the contrary, tries to understand a bit, models that bit, seeks feedback and then starts again. The model is built iteratively and incrementally, in short cycles. Agile builds the model through feedback.

I started thinking about all agile components I've been thinking lately and realize they all seek feedback.. a lot of feedback. Think about it:

Technical components: TDD, automation, continuous integration, etc.... TDD seeks continual feedback. Does the code do what is specified in the tests? The execution provides the feedback immediately. Automation.. tests are executed all the time so that the team receives feedback. Continuous integration provides feedback of whether the local changes integrate well with the whole (in a neutral environment).

Process components: an incremental and iterative process seeks business feedback. Incorporating this feedback makes the software much more valuable.

Human components: Agile seek to augment the flow of communication. The best communication is the one that includes feedback, because everyone gets to know what is understood (Cockburn says the best one is talking face to face, where you even see the feedback in the other person expressions)

Feedback, feedback, feedback.. Agile relies on feedback to bridge the gap between the business domain and the model being built. Technical and business users collaborating to create a valuable model. Knowledge is built through feedback. Software is built through feedback.

Agile is Ruthless Automated Testing

Test automation is one of these components whose importance is difficult to understand at the beginning. It's not obvious and by consequence it is often underestimated. Probably, it should have been stated in the Agile Manifesto in a more obvious way (now you need to know what 'working software' means for the signers). What's worse, it is difficult to do and it requires a great deal of work!!  For what??!! Let's see.

Why Automated Tests are important in an Agile Context

Automated tests are important both in projects that use traditional and agile methodologies because they allow to regress all the functionality without effort. However, in agile projects they are more important. Here are the reasons:

1. It supports a sustainable process.

Agile states the importance of a sustainable process, that is a process that allows to deliver features continually in a long period of time (i.e. deliver features each iteration, while keeping the existing ones working). In other words, a process that maintains the "cost of change" stable (not growing exponentially) is needed.

Getting to this point is really hard. In a short period of time (an iteration), new features need to be constructed and old ones need to be tested. As more and more features exist, there is more and more regression work, which becomes very time consuming, tedious and error prone. Automating this work becomes the key point to keep the process sustainable.

Agile suggests there should be an extensive suite of automated tests that cover most of the functionality. This "test harness" should be running continually to maximize the feedback and it should be up to date at all times. This means that for every new functionality added to the project, there should be tests that are added to the test suite.

There is another important point on sustainability. Part of being able to have a sustainable process is minimizing the introduction of bugs during the iterations. Computer systems usually have a large entropy. That means that changing one part of the system may impact other areas which are very difficult to predict just by analyzing static code. Good automated tests provide this information very quickly allowing developers to make the changes and see the results immediately. This continual feedback prevents lots of bugs from appearing, amplifies the knowledge of the developer and also gives the courage to introduce changes in the design or make complicated refactorings.

2. The quality of the code is increased

This is like a turn around of things. The main objective of tests is to regress functionality, but it has been proven that just the fact of having to write them improves the quality of the code under test. Interfaces are better understood and designed and the code is cleaner. It also limits the code to do exactly what is supposed to do, as programming is done to make the tests pass.

TDD takes writing tests to the extreme. Tests are written before the code. The code is then written to make the tests pass. So, the tests drive the development. This technique has many advantages: We can be certain that the software is working at all times (which improves the morale) and there is a very high code coverage which gives the possibility of making bigger changes in the code.

3. It allows the team to be agile

This reason is very tied with the first, but I think it's worth mentioning it in a separate point. The design in agile emerges iteration after iteration. Every iteration, the design of the application could be changed to accommodate the new requirements. This changes should be done in the cleanest way (It is not acceptable under the agile principles to accommodate changes with patches). The cleanest design for the new requirements should be thought out and all changes and refactorings should be performed (otherwise, it wouldn't be sustainable)

There is also the possibility that features that have been completed need to change (possibly in reaction to market changes or because the implementation of a new user story so requires). Agile is prepared for very dynamic environments and therefore it should be prepared for these changes. It's nothing but the test harness what allows to make "big" changes or turns of direction.


4. It improves speed

With all the work involved in creating and maintaining tests, it can be easily derived that a project with automated tests would take longer to finish. Well, this is not often the case. In many occasions the speed is improved. The main reason for this is fewer bugs are introduced along the way. The flow is stable and, at all times, the code is known to be working. Even more, if there are bugs, these can be fixed with a fewer probability of introducing a new one (minimizing the effect that Brooks called: one step forward, two backwards)

Dean Wampler's post explains this in more detail:

Basically, what the graph represents is a comparison between a traditional project without automated tests (orange line) and a project that uses TDD. When the project is reaching the end (up until this moment the speed seems to be greater) QA starts working and discovering errors leading to a big increase of work. Not having integration tests leaves the possibility of discovering integration problems as well. After developers start fixing bugs, new ones can be introduced more easily because there is not test suite that provides feedback on the changes made. Finally, the project ends with all the stress derived from having "discovered" all the problems at the very end. On the contrary, a project that uses TDD has more work at the beginning, but then it maintains a more stable flow of work. At all times, the code base is known to be working and therefore the expectation is to have a smooth ending.

5. It lowers Maintenance Costs

Most of the systems have a much greater cost in their maintenance phase than in the construction phase. A lot of systems that take only a few months to be built are years in production. The cost of maintaining projects without automated tests is considerably higher than maintaining one with a good test automated suite.  Fixing a bug many months after it has been introduced is extremely difficult. Even more, the changes necessary to fix the bugs may have unforeseen consequences. In traditional projects, Brooks reckons that fixing a bug during the maintenance phase has a 20% to 50% probability of introducing a new bug. He mentions that the reason for this high probability is again the high entropy of computer systems and also the possibility that these bugs are solved by people who was not involved in the construction of the system.

An automated test harness is invaluable in these circumstances.The tests allow the developer who will fix the issue to understand the logic of what needs to be solved. After introducing the fix, it allows him/her to be more confident that no new bugs have been introduced.


6. It is the best documentation

Automated tests represent the best possible documentation. Conversations with the Product Owner and the different stakeholders live into GUI tests and design discussion live into integration and unit tests. The key aspect is they are executable documentation. They are much more valuable than static documents like models and written documentation because they provide continual feedback. Besides, they are written in a language that provides no ambiguity.

7. It supports other practices

It is important to point that test automation provides a lot of advantages per se, but it also supports other practices allowing to reach the synergy Beck talked about in his first XP book. Automated tests can be a great help in requirement specifications (with the latest BDD approaches, the Product Owner is able to write the requirements as executable specifications). It supports coding: Agiles strives to have clean code that works at all times and automated tests are a great help in this quest. It supports collective ownership, as automated tests provide great help to understand certain aspects of the functionality. It supports refactoring. In fact, it would be impossible to refactor continually if there isn't a test harness that prevents the introduction of bugs. In conclusion, if it is performed correctly, it makes all the other practices work better. If it is not done at all, other practices are debilitated. The whole approach relies on having automated tests to drive the project.

Why don't we automate them then?

Which are the ropes that prevent us from doing it, even if we understand all the advantages?.

1. Tight schedules

Whenever we feel the pressure of the schedule, we stop writing tests (or don't fix the tests that are broken). After all, tests don't constitute the core of our system. Of course, this has direct consequences in the near future.

Ward Cunningham coined the "Debt Metaphor" to explain the refactorings they were doing at WyCash product. He explained that the knowledge gained during the project need to be reflected in the code. In other words, the code should look as if it was written with all the knowledge in mind, while at the beginning fewer things were known. To justify the design changes and refactorings, Cunningham drew the analogy to financial debt. The needed changes represent interest, which if it was not paid would inevitably increase and would inevitably have to be paid later at greater costs. This analogy was expanded to all tasks in software development that might be postponed (tests, TODOs, etc.). Postponing them generates an immediate increase in speed at the cost of creating debt. If this debt is not paid soon, greater interests would have to be paid later.

2. Technical Difficulties

Writing tests is really difficult. It takes time to understand how unit or integration tests should be written (and a bad written test is useless or even worse: it creates a false sense of security). Besides this, there is also the need of investing time and effort in creating an infrastructure for testing (if there isn't anything that could be used).

A Project's Strategy towards Automation

Crispin/Gregory talk about defining an strategy towards automation. An automation strategy defines the plan to deal with automation in a particular project. These are just one of the few things that need to be defined:

- Layers that are going to be tested
- Tools that are going to be used
- The process that is going to be followed to commit code, create the tests,  what will be done if the build is broken, etc.

It is important to have everything in mind when thinking about the strategy

Technical factors, such as:
- Available frameworks and tools
- Familiarity of the developers with the frameworks and tools chosen
- Initial necessary investment (in developing the tools or training)

and factors more related with the business, such as:
- Importance of the project for the enterprise
- How much business involvement will be during the construction
- The life of the product post implementation

Each project is different, so each project will have its own strategy (i.e. there isn't a best strategy). Green field projects will have a different strategy than projects with legacy code. The technologies chosen for the project are a decisive factor as well (not the same to do an outlook plugin, an iphone application, a CRM, a mesh, etc).  All the team should adhere to this strategy, otherwise it is doom to fail.

Conclusion

Test automation is hard, time consuming and doesn't add value directly. However, not doing cripples many of the Agile benefits. An Agile project with no test automation is not sustainable, its quality decreases and has many chances of taking longer. In a project without test automation, is hard to see where you are standing (Is everything working?). And it definitely requires more repetitive, boring and error prone work.

Every project is different. The needed product is different, under different circumstances and with different groups. Everything needs to be taken into account to define a strategy towards automation. The strategy should be one that everyone believes and commits to.

References

1. Lisa Crispin, Janet Gregory - Agile Testing: A Practical Guide for Testers and Agile Teams.
2. http://www.scrumalliance.org/articles/106-definition-of-done-a-reference
3. http://www.agile-software-development.com/2007/07/definition-of-done-10-point-checklist.html
4. http://blog.objectmentor.com/articles/2007/09/30/why-you-have-time-for-tdd-but-may-not-know-it-yet
5. http://gamesfromwithin.com/?p=50
6. Kent Beck - Test Driven Development - By Example
7. http://www.youtube.com/watch?v=pqeJFYwnkjE
8. http://en.wikipedia.org/wiki/Technical_debt

Agile is Clean Code

But ... Isn't this a requirement for all approaches? Why do I have the impression that in Agile, the technical aspect is more important? When I was at University, I remember vividly having heard (and unfortunately later repeated) that the programmer had one of the less important tasks in the chain of producing software. The most important, more senior and smarter people are the architects/designers that analyse and design the application, giving the programmers some diagrams that they 'just' have to translate into code. That seemed like an easy task!! 
   

What means Clean Code?

Ron Jeffries says that we should write "clean code that works". Uncle Bob then made an entire book of Clean Code. What is clean code? Following uncle Bob's explanation, at the high level, it is code that is well structured and which follows SOLID design principles. At a lower level, it's code that has meaningful names, good and useful comments, elegant functions and formatted code.  It's code that expresses the intent of the developer in a clear way. It's code that contains no duplication. And is code that is easy to understand.


And how do you know it works? You don't know because you code it and you are a great programmer :-). You know it because there are automated tests that certify it. Agile development relies on test automation to know that features work and to know thay they do all the time. Beck says "Software features that can't be demonstrated by automated tests simply don't exist". Test automation is one of the pillars of clean code because it allows to continually refactor, it allows to redesign and ultimately it allows to deliver a continuous flow of value.

Why is so important in Agile?

These are a few reasons to justify the 'pain' of writing better code:

1. Cost of Change is lowered: Agile welcomes change, even late in the development process. However, to be able to change, it should be cheap to change. Code that is well designed, easy to read and thoroughfully tested is easy to change and can be changed without fear of introducing new bugs. On the contrary, code that is hard to understand, is not well modularized and has no automated tests is difficult to change and the risks of introducing bugs while modifying it are many.
2. Iterative & Incremental Development means more time coding: In sequential development, there are big phases of analysis and design before the coding phase starts. When the code phase starts, most of the design decisions should have been taken, so development proceeds fast. In Agile, development starts earlier so this phase takes more time. As the code base needs to be manipulated for a longer time, it pays to have it clean. Reading Clean Code, one of the a-ha moments that I had was in the chapter where Martin explains that in the life of a system, the majority of the time is spent reading code, not writing it. I started thinking about my experience, and that was entirely true. I have worked in many systems that already have a lot of features in it. In those systems, each time that I needed to add a new feature, I spent most of my time finding where to put the feature and how to accomodate it to the existing features than actually coding it.
3. Iterative & Incremental Development means the code is changed frequently: Design is performed incrementally in Agile. Every iteration, new features are included in the code base. The design of the system should be one that cares about all features included until that moment. Therefore, this means that a lot of times the existing design needs to be modified. If the code is not maintained clean, understanding and modifying it may become difficult in a short period of time. 
4. Working software is more important than Comprehensive Documentation: This is what the Agile Manifesto says. But having the code base in good state, with good comments, good names, well modularized and with a comprehensive set of automated tests is the best documentation that a developer may have. Been able to understand a piece of code easily because it's simple and it expresses its purpose with clarity is much better than going through UML design documents. Being able to run and debug a set of unit tests for certain functionality provides the best tool to understand that functionality. After all, what really happens is what is in the code, not what is in the documentation. Code is always up to date while documentation is hard to maintain. 

Why don't we do it then?

Lack of skill? Sometimes... This is a craft. A difficult one and we need to spend a lot of time getting better on it. Commitments.. Yes. Our own commitments and the commitments of our managers. Being under pressure and with the deadlines on sight, make it 'work' takes another meaning (I mean, you just want to throw some code that at least compiles and shows something on the screen). I won't follow. There are always plenty of reasons to do things worse!!

Humm.... but Scrum doesn't include a topic on technical practices

I've seen great debates last year over the lack of technical practices in Scrum. Some people believe it is a shortcoming of Scrum while others say Scrum is a product development framework and therefore it is out of scope to include a technical section. Without entering into this debate, something that I've seen a number of times is software development teams starting 'just' with Scrum, leaving the introduction of some XP practices like TDD for the future (if you take a look the popularity of XP and Scrum, I guess many people observed the same!). This may be justified by an approach where changes are introduced gradually (after all, Scrum per se represents a major change at the organizational and process level).

But what happens if you start with 'just' Scrum?. Basically, I believe Scrum alone is not sustainable. At least, in software development it is not. As iterations go by and the code base grows, there is more and more work to finish each feature. By consequence, teams cannot keep their commitments, the business people get mad and you hit the Scrum Wall (ouch, hit it many times)

This is still a topic I think about often. Scrum, per se, is not sustainable in software development. However, it is the most succesful process in the Agile world. It seems that leaving technical aspects out of it is both something that has help Scrum become more popular  and the reason of many of its failures in the development world. 

Conclusion

Clean Code is one of the pillars of Agile. Being able to deliver clean code that works greatly enhances the chances of deliver value sustainably and it makes our life as programmers better. Clean code provides the best ROI and the best documentation. Of course it is difficult to do it and it certainly takes a lot more time than writing crappy code. However, by not doing it, we lose a lot of the advantages that Agile claims.

Questioning Scrum

I have been working with Scrum for the past 4 years. I love it. It was my introduction to the Agile world and It is so much better than what I did before. Now I am in a moment where I am questioning some things. I attended a couple of conferences about Kanban (so I am far from expert), but it was enough to plant some seeds of doubt about the things I do with Scrum. Below are some examples

Cross-functionality

- Scrum states that cross functional teams are needed, but the way to enforce it usually fails. Having iterations with stories that correspond to each area of specialization 'suggests' specialists for each story. I have struggled with many teams to be more cross-functional, to pair and to spread the knowledge, but Scrum doesn't give the tools to do that per se. On the other hand, Kanban with its 'minimize work in progress' principle enforces cross-functionality in a much better way as stories are not pulled until one of the current ones is finished. This 'forces' developers to pair or just work on areas of the system where they are not so comfortable.

Attack the risks

- Previous point also applies to tacking the risk first. There's usually the case in a scrum iteration that individuals choose the tasks they are more familiar with or they feel more comfortable with (yes, I do it all the time). Scrum 'sort of' allows this. In a self-organized team, team members decide which task they want to work with. How can we be biased to choose the task where the bottleneck is or the task that is representing the highest risk?. If there is no option other than working in the bottleneck/risky task, we don't have any other choice.

Sprints:

- Having iterations of equal size forces the team to break up the functionality in chunks that fit into a Sprint and also forces closure during the iteration to be able to finish them. A cadence is created as iterations go by and there's usually a sense of urgency because there is a lot of work to finish a story end to end. This is really nice but there are things that I don't like about these sprints. Imagine, we, the team 'commit' to a certain amount of work. When we are too careful with the estimations, all work is finished either 2/3 days before, and we (usually prefer to) relax and wait until the next sprint. What happens if we over-commit? We usually works harder to try to finish (which is not that good) and if we don't finish and the story is rolled, that story stretches in the next sprint in unthinkable ways!!. No scenario seems to be perfect. Personally, I prefer more stability. Committed and motivated people working 8 hours a day to complete the work. Does this mean stories should not be estimated? Well, I think in highly exploratory projects, stories should still be estimated even if using Kanban and the team should strive for closure in the estimated time. But the sprint fixed size sometimes is an artificial constraint that creates certain dysfunctions.

Iteration Plannings:

- I have been in many iteration planning where stories are 'guesstimated' because there is not enough information at that point (in 3 week iterations, that is entirely possible). Teams are encouraged not to pad, but when there's too much uncertainty, team members fall into this. Estimating the story when it's pulled allows in many cases to have more information, to avoid assumptions and makes this meeting faster and more productive. Probably, this is a case of 'Decide as late as possible'. For example, if one story depends on the another and many of the uncertainties will be cleared when then first story is completed, why spending so much time to speculate in estimating the second? (we do this very often in Scrum, don't we?)

- Iteration Plannings tend to be to large. And sometimes boring. Scrum suggests a ratio and the meeting should be timeboxed. If there's uncertainty in some of the stories, this could get worse. Who hasn't been in endless debates that later translate into a short 2 hours research that sheds all the necessary light? I guess this point is very related to the previous. A crisis of faith in estimating things I don't understand.   

Scrum taskboards versus kanban boards

- Kanban boards provide more information that Scrum boards. They allow to visualize flow and discover bottlenecks. Many times when working with Scrum I find my self looking at both the taskboard and the burndown to give me a real sense of the progress. With scattered tasks all over the board, usually I don't understand where we are.

- Be able to spot the bottleneck and provide an impersonal way of pushing the team is great. Constraining work in progress in certain phases forces the whole team to focus on the most critical things that will make the iteration successful. And this is not intuitive. Personally, If I looked at a scrum task board, I usually pick the tasks I am more familiar with even if they are not the highest priority or the ones that minimize the risk in the iteration. I don't think I am different than the majority :-)

Daily Standups:

- Something I read recently (and I liked) is Kanban teams do the standup looking at the board instead of looking at each other. I like that idea. I believe it foster collaboration in a less personalized way. Let me explain: sometimes I think Scrum daily standups put too much pressure on the people that are going slower or are stuck. People is looking at each other and sometimes there could be managers (chicken, but managers). I believe this could cause a dysfunction: lying about the status. Or even worse. Try to finish faster, dropping quality. Focusing on the board switches the focus from a person stuck to a task stuck. It's subtle. I like it.

All in all, I think kanban brings values that would make a team better. Minimize work in progress (and thus reduce the size of the increments), defer decisions until the last reponsible moment (estimate when you have all the needed information), focus on the problems and help resolve them (as opposed to help someone resolve it). I never used Kanban in practice. But I am at a point that with what I read/hear, I can spot moments or situations where we are not doing things in the best way with Scrum. I am not saying these are reasons to justify moving from Scrum to Kanban. And I am not saying these are shortcomings of Scrum. These are just some questions that arise from knowing that there are other ways of doing things. And I believe this questions are helping me improve how we do things now.

Agile is Self-Organization and Self-Discipline

Agile teams are self-organized teams that work in an environment that has certain constraints to achieve certain goals. A self-organized team lacks a central authority. Instead, members self-organize and lead themselves to achieve the goals.

To understand how Self-Organization works, we can start reading about "Complex Adaptive Systems". In complex adaptive systems, the solution emerges. The term "emergence" means that "Rather than being planned or controlled the agents in the system interact in apparently random ways. From all these interactions patterns emerge which informs the behavior of the agents within the system and the behavior of the system itself." Complex Adaptive Systems accurately describe a software development ecosystems. Members in this ecosystem usually take every day decisions that impact the final product and they interact with other members to do that.

Self-Organization doesn’t mean anarchy or sloppiness. On the contrary, Agile self-organized teams are very disciplined. This discipline is the one that is borne because of the high standards of the group and because no one wants to disappoint their peers and not because of rigid orders of a manager.

Self-organization needs to happen within the limits set by the organization and guided by leaders. Managers still need to set the direction, the constraints and the guidelines that the team needs to follow. It is also important to have leaders within the team to coach and spread the good practices. 

Why?

Which are the reasons that justify having this structure instead of a more traditional command and control structure. This is a small list of those:

Self Organized teams take better decisions: The fifth lean principle in the Poppendieck's "Lean Software Development" book is Empower the team. Empowered and educated employees guided by a leader are motivated employees that can take better decisions that their managers. Scientific Management, as stated by Taylor, was designed with another type of employee in mind.. very different from the software engineer. In today, knowledge-based organizations, delegating power down (empowering) has proven to be much more effective because the engineers working at the front line have much better information and because they have the knowledge to take those decisions. 

Individuals in a Self-Organized team are motivated: Motivation comes from participation. Being part of the solution… Something to keep in mind when working with knowledge-based workers is they are highly educated people. Therefore, motivation not only comes from the salary or the position, but also by being able to do something that satisfies them.  

Self-Organization improves trust and commitment: Knowledge-based organizations are totally dependent on the commitment and ideas of their employees. Knowledge is a resource locked in the human mind. As the Novel laureate economist  Friedrich Hayek has argued, "Practically every individual... possesses unique information" that can be put to use only "with his active cooperation". 

Self-Organization enables innovation: Trust and commitment makes people go beyond their call of duty by sharing their knowledge and applying their creativity. The synergy created in the interaction from individuals with this attitudes is one of the key enablers to build innovation. Contrast this to other structures were employees are just told what to do. In this case, what the person can contributed is much more bounded. In Self-Organized groups, innovations thrives.

The best solutions emerge from self-organized teams: last but not least, let’s mention one of the principles in the Agile Manifesto. I completely agree. A self-organized solution contains a mix of different backgrounds on it. There is no comparison between a solution thought by just one person and one reached by a group that went through different options and agreed on the best one.

Managers to Leaders

If members are not told what to do, you probably would wonder what happens with manager. There is a shift in the way management is performed. Managers become leaders in Agile. They don't tell its employees what to do. They fix the goals and set up the constraints to get there. And they lead by example. Lissa Adkins states in her article "The Manager Role's in Agile" that "agile managers coach, inspire, and lead teams more than they measure and manage them."

Wait a minute.. Does this mean managers don’t take decisions anymore? I had this doubt for a lot of time, until I read Highsmith “Agile Project Management” book. The answer is “yes, they still need to take some decisions”. Even more. The group expects the leader to take some decisions. I’ve seen it many times. When the leader is respected, there are a lot of people that even prefers the leader to take the decision for them. But to reach this point, there should be respect. Lots of it.

I just read the paper “Fair Process: Managing in the Knowledge Economy” by Chan Kim and Renee Mauborgne. This paper explains very clearly how people respect and even commit to decisions they have not taken if and only if the process is “fair”. A fair process is transparent and known before the decision is taken and it allows for the people affected to at least expressing their points of views. The process is as important as the outcome. 

Conclusion

Self-Organization is one of the tenets of Agile. It improves trust, motivation, commitment and most of all, it improves the quality of the produced work. Managers and organizations used to old command and control structures need to change their beliefs and their culture. Agile leaders need to understand their new role, which is by no means easier than before.

Can estimations be used to push the team? How?

In all teams, there are guys that are really performant, there are average and there is people that are slower (be it because of skill reasons, personal reasons or whatever). When tasks are estimated in ideal hours using a technique similar to planning poker (where everyone contributes), the result should be an estimate that falls into the average, right? To be more clear, if the task is taken by a fast member, probably it will be finished before the estimated time. If it's taken by an average, it would finish around the estimated time and if it's taken by a slower member, it will take more (probably much more) that what was estimated.

So these estimations should give us an idea of where we are in the Sprint, right? The question is: can we use them to 'push' the team? If they are used to push the team, how can it be done without hurting the sensibility of anyone and without causing people fear of taking the most difficult tasks?

These are some options:

- Asking the individual/s that hold the task why is taking so long in the standup.. This is brutal and I don't see any possible benefits (probably people will be terrified of taking the most difficult tasks very rapidly)
- Asking the whole team why certain tasks are taking longer. Much better cause there is depersonalization of the problem.
- Try to make the problem more visible. Using information radiators, everyone should be able to see the problem and pitch in to try to solve it.
- Minimize work in progress. This is another, more effective way, to make the problem visible. If no new tasks can be pulled because there is something stuck, the group as a whole will try to un-stuck it. Completely depersonalized and very effective. Wait... I am not using estimations this way :S

Ultimately, Agile relies on a group of motivated and committed individuals. If the speed at which the group is going is not enough to reach the objectives, it is a problem of all the team: managers, product owners, developers, etc. The group as a whole needs to resolve this problem. They need to figure out how to go faster. If the group shares the responsibility this way, they will find the best way to overcome it. However, there is a basic requisite that the group must hold: There should exist trust in the group. It should exist the trust that allows you to tell the group that you are stuck and need help without been judged. There should exist the trust that allows to treat the problems as problems of the team.

Comments???

The Agile Architecture

There are some big graphs, so I published the google doc as well (it looks better): http://docs.google.com/View?id=dhpj7455_67gkwk3bfr

When I started with my first Agile project, I just knew I liked it. I felt better working this way, I felt that we delivered better results. I was thrilled by the quality of the code, I felt good with my team mates.. But they were just feelings. I couldn't explain why. With the excuse of having to complete my MsC thesis, I decided to keep investigating and learning about Agile, . I went to my first Agile course (hey Matt, it was cold in that room!), kept working in Agile projects, read some books, blogs, forums, went to some Agile conferences, became a Certified Scrum Master (wow!) and started having Agile friends :-).


So after 4 years, what is Agile? Well, what I can tell is it is not a methodology (Haven't you read at least a post that starts with "The Agile methodology..."?). The most accurate definition I have is Agile is a set of values and principles listed in the Agile Manifesto... But probably, this manifesto has too much knowledge condensed in a few words. In this post I want to define the Agile architecture (yes, this is upfront architecture!). What I mean by architecture are what I considered the most important components in an Agile development team (I am a developer, so it is from a developer's vision).

This is what I came up with:

First, I defined what I consider the most important objective of Agile: being able to deliver value sustainably, with the required quality and in a changing environment. I did a post recently in which I list why Agile provides better value.

Then I tried to list the most important components and after having them, I tried to categorize them. I think there are 3 categories:

1) Components related to the technical field. I am a developer and so I believe these components are really important in any software development team. Inside this category, I put 3 main components.

    a. Simple Emergent Design: being able to evolve the design in every iteration is crucial to being able to deliver a continuous flow of value. This component is a consequence of doing iterative and incremental development, and relies on having automated tests and keeping the code clean via opportunistic refactoring. It also relies on having the latest code base at all times (continuous integration).

    b. Technical Excellence: this includes opportunistic refactoring, clean code and ruthless automated tests. This component is big as its importance to successful agile teams as it supports doing evolutionary design, it allows to adapt to changes and it supports having a process that relies on having a lot of information on the code itself. 

    c. Continuous Integration: This is a small component that supports other components such as technical excellence and emergent design.

2) Components related with the process in place.  

    a. Light Process: Agile needs a process that allows to "welcome change, even late...", a light process that reacts and adapts to change. The ceremony and the artifacts should be the minimum that allows to coordinate the project at hand (otherwise is hard to turn). The process should encourage introspection and optimization based on it (kaizen). To accomplish this, Agile relies on a self organized but very disciplined team and the software engineering practices included in the Technical Excellence component.

    b. Incremental and Iterative Development:  I am not sure if this component should be part of the light process (probably yes). Anyway, I wanted to stress the importance of having a process where development is performed iteratively and incrementally. 

    c. Self-organized & Self-disciplined: Agile relies on a team of committed and passionate software engineers. Maintain technical excellence relies on a lot of discipline. Self-organize successfully relies on human components: good communication among all team members and the will to collaborate.

    d. Transparency: The process should encourage transparency. Transparency improves collaboration and allows to reduce the number of needed artifacts.

3) Human components

    a. Collaboration: All team members, whether in the product or development side, collaborate with each other. Success is measured for the whole team that participates in the project, not by sub-team or individually. If there is good collaboration, there's no need for artifacts that just have the purpose of make someone responsible and the process can be lighter. 

    b. Communication: The flow of information among all members should be taken to the maximum (possible) as members with more and better information translates into improvements in the results.

These are the areas where I would map the Agile values:

And the Agile principles:

Final Thoughts

I am not sure if this makes sense or not. I know making this exercise allowed me to visualize what components an Agile development team should have. I've been following some threads where they discuss what is missing from Scrum and started wondering: Is there a methodology that follows all the Agile principles? Is it straightforward to map all what is needed to make an Agile Development team from the Manifesto? (as I said before, the Manifesto seems to contain the conclusions of many years of experience of these guys). I am also interested in Process Improvements Frameworks and so I was wondering whether it would make sense to define (as CMMi does) the Agile process areas (what I called components here) and the suggested practices in each area? I am not sure about this..When you are in the Shu level, you need to follow a methodology to start. Perhaps something like this would allow to choose the methodology or know in advance what needs to be addition to the methodology to "comply" with the Agile values and principles.

Agile is Iterative and Incremental Development

Definitions

Agile is iterative and incremental development. Iterative and incremental development was borne in response to the weakness of the Waterfall model.

In Waterfall, the product is developed sequentially, delivering all the product at the end of the last phase:

from wikipedia: http://en.wikipedia.org/wiki/Iterative_and_incremental_development

The problems with this approach are:

- Specifying all the requirements at the beginning is very difficult. When the customer is able to see a working product, is very expensive to make changes.

- It's very risky. Developers starts facing the real problems after 2 entire phases, which could be in the middle of the project. A lot of money has already been expended at this moment. 

The Agile approach to overcome these problems is to deliver the software in increments. In each increment, activities from all these phases are included.

from wikipedia: http://en.wikipedia.org/wiki/Iterative_and_incremental_development

It is important to understand the different between "incremental" and "iterative": 

In incremental development, work is break up into smaller pieces which are scheduled, developed and integrated when completed. An increment is an increment in business functionality. In other words, an increment in Agile delivers something new to the customer which s/he can see and experiment with. To be able to accomplish this, work is break up based on functionality. A feature is developed in its entirety, from the UI to the back end in an iteration. 

Iterative development means the product is built in iterations, where each iteration expands the product until the project is completed. As the process is also incremental, each iteration includes parts of all phases (i.e. in each iteration, there is some analysis, some design, some code and some testing). 

When researching to write this post, I came accross this article (http://www.stsc.hill.af.mil/crosstalk/2008/05/0805Cockburn.html) written by Cockburn. Something that caught my attention about this article is he states that if after an iteration is completed and the feedback from the customer is received, there isn't time to incorporate these changes, then the process isn't really iterative. There should be scheduled time to rework, to apply the changes the customer requested, to revise the performance, to redesign or the "iterative" part disappears and we are following into the same Waterfall mistakes. To be honest, I don't understand very well why it would stop being iterative. The iterations are still there and would expand the product in each iteration but not where the customer is expecting. To be even more honest, I always saw them as one entire concept. If the delivery is incremental, is there any other way to do it other than iteratively (recursively?).

Pros & Cons

Basically the advantages are the disadvantages of the waterfall model:

+ The development team and the product team learn from what has already been constructed. The development teams face the difficulties early in the project life. The product team starts looking at the product early as well and starts materializing their ideas and suggesting the necessary changes needed to obtain the best possible product. 

+ Value can be delivered early. Doing incremental development is the basis for being able to delivered a partial release.

+ Risk is reduced. Developers "attack" the riskiest features early in the project's life.

+ It's the approach to take when exploring, when working on a not known domain. It's the way scientists work. They make an hypothesis and try to prove it via experiments. Spending a lot of time architecting and designing does not make a lot of sense in these types of projects. 

What are the cons then?

- The only disadvantage I can think of is it's difficult. Squishing all phases into a short iteration presents many difficulties to all members of the team. Developers need to accommodate the feature to the existing design. Testers need to start thinking about the test cases in the air, when the feature doesn't exist yet. All members of the team need to work concurrently on the same feature, which requires the team to coordinate the work very well. Add to this that development needs to be sustainable and therefore completing a unit of work means not only delivering the functionality. It means delivering it with the best possible design, with clean and refactored code and an automated suite that can regress this functionality in the future.

Architecting and designing in an iteration....?

This is perhaps the most controversial topic in incremental development. Detractors of Agile usually ask where (the heck) does the architecture and design fit into an iterative and incremental approach!!!

At the beginning of the project, there is a period where the vision is defined and the basic requirements are gathered. After that, there should be time to define the most important aspects of the architecture. The length of this time would vary depending on many factors. If the  project is complex, but there is a lot of certainty it makes sense that this period is larger. As certainty decreases, spend time at the beginning makes less sense as conditions will probably change. Remember Agile needs to maintain the curve cost low. Therefore, decisions that later would imply big costs should be taken at the beginning. Highsmith calls this making a "balance between anticipation and adaptation". Anticipation is up front design. Adaptation are the changes needed to react to different conditions in the course of the project.

When iterations start, for each new feature that is constructed, there is design. The design consists in accommodating the new feature in the best possible way. I don't know how you feel, but I feel design is performed with better information. It is performed based on tangible components. Personally, I do the design understanding the problem better.  Of course the design for the existing features may change to make the new design that contains all the features a better design. Don't forget that Agile is also about being able to deliver value sustainably. If design deteriorates with each new feature added, technical debt starts rising and it becomes more costly to add new features in the future. Another important point is Design is made with the YAGNI principle in mind: "Do the simplest thing that could possibly work". Let the abstractions be borne as they are needed. Don't make decisions based on assumptions about the possible necessity in the future. Ah, one last important point: "Simple is not simplistic". The design of each feature ends up with the simplest but cleanest and most elegant way you could possibly think of (I say you could possibly think of because making good designs is not something that you'll do the first day you start developing - that doesn't prevent you from following these principles, as I do :-))

Being able to change the design in each iteration relies on other technical practices such as refactoring, continuous integration and automated tests. Without them, making changes would be very risky. Refactoring in each iteration allows to have the cleanest code base each time a new change is required. I believe anyone that has developed knows there's always a couple of options to do something: the clean way and the hack. The hack is the quick and dirty option, useful in the short run and painful in the long run. The cleanest way includes refactoring and of course more work. Automated tests provide a harness that allows to apply the changes in a safer way. It would be impossible to make continuous design changes if it weren't for the automated tests that provide certain security that the existing features keep working after the changes. 

To Timebox or not to Timebox

I never thought about it until I read Johanna Rothman blog... Every time you have a task to perform, you have 2 options to tackle it. If you understand very well the scope of the task and is something that can be done in a reasonable amount of time, you just go for it. You work with the objective of finishing the task. What is the problem with this approach? If the objective is blurred or the task is very big, there is no sense of progress and we can easily fall into extending the task ad infinitum. Timeboxes bring the reality of date constraints to the task at hand. If you plan to tackle the task with timeboxes, you allocate some time, estimate what you would be able to complete in that period of time and then review the progress and take decisions based on it.

Timeboxes bring these benefits software development:

- "Timeboxing forces closure, it forces the team to deliver something concrete" (Highsmith). When exploring, it is very difficult to scope a feature. Teams are discovering and therefore, times can expand indefinitely. This contrasts with the date constraints that projects always have. Timeboxes force a date constrained exploration and it forces the development team to focus on delivering something.

- Timeboxes are short term adventures, marked by decision points at the beginning and at the end. These decisions points allow the business to take decisions. The word "short" is important here. Timeboxes are short while scope-boxes tend to be larger. 

- Timeboxes create a cadence. The team enters a cycle that repeats every 2/3 weeks. After that period, the team review how it performed, adapts and recommits for the next iteration.

So what will you do, timebox or not timebox? Scrum and XP use timeboxes while Kanban doesn't enforce them. To make the decision, bear in mind what timebox provides. I have seen a few examples where the teams were struggling to work in timeboxed iterations when it just didn't make sense to them (e.g. production environments working with Scrum where they were getting requirements all the time and therefore they couldn't freeze a chunk of work for X weeks) or the exploratory factor was very low (basically the user story always takes a certain amount of time). In these cases, timeboxing doesn't add anything and I would just opt for a scopebox approach. On the other side, if the project is highly exploratory, the timebox iteration allows the team to focus and close a piece of functionality. It forces them to scope that piece of work and not expand to provide features not required at this time. Whether you timebox or not doesn't make you more or less Agile. At least, I don't see any reference in the Agile Manifesto to timeboxing.

Conclusions

"Iterative, feature-based delivery is the cornerstone to early and often delivery of value" (Highsmith). Being able to produce a partial product allows to have a common ground for the product and the development team to discuss and keep delivering value. During an iteration, a lot of new knowledge is gained which is used by business people and developers to make better decisions in the future. The technical risk of the project is tackled as early as possible. Of course iterations don't start immediately. All Agile project start with the basic architecture and a bunch of important decisions. When iterations start, design is done incrementally. Being able to design incrementally relies on doing other engineering practices, such as refactoring and automated tests.    

Update 2/23: I just made the click with the meaning of an iteration. The key is that an iteration is fixed length. This is in contrast with a pull system like Kanban that pulls the work. So Scrum/XP are incremental and iterative and Kanban is just incremental. I am thinking that perhaps the title of the post should be changed to "Agile is incremental development" as the agile manifesto doesn't say anything about being iterative. (At least, this is my interpretation of this principle "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.")

6 Reasons Agile Value is Different?

A few weeks/months ago there were some posts related to the importance of value in the Agile world and also some discussions of whether it should be mentioned in the Agile Manifesto. So the question that I had at this moment is how is agile value different from the value delivered by other approaches. These are the 6 reason I can think of to justify Agile value is different:

1. There is a focus on delivering what the customer needs

Waterfall relies on the customer specifying exactly what they want at the beginning of the project. Dealing with changes later is very expensive because the cost of change is high in a waterfall approach (based on Barry Boehm's famous Cost of Change of curve). Agile, on the other side, acknowledges that what the customer is expecting is difficult to express in words/models and can probably change during the duration of a project. Therefore, Agile welcomes change, even late in the development process and adapts to fulfill the customers expectations.

How is this achieved? With communication, collaboration and a lot of feedback. There is a lot of communication and collaboration during the whole duration of the project. The customer actively builds value with the development team. And the development team builds what the customer wants. Conversations don't stop with producing a requirements document or the best model. Conversations continue permanently because conversation adds context to the information. Grasping the business knowledge needed to deliver a product that provides value is really difficult and relying solely on written words is really risky. To allow for more and better feedback, software is delivered in increments, where each increment finishes with running tested features that the user can experiment with. This allows the user to really understand how the product is going to be useful and make decisions based on a working product.

This focus on the customer needs wants to be pushed even further. I read a couple of tweets a few ago where Cockburn was presenting some possibilities for the creation of a User Manifesto (http://alistair.cockburn.us/User+Manifesto). I understand this manifesto as the need to further think on the needs of our customer, on trying to solve their problems better, on fulfilling their expectations with a great piece of software.

2. Creativity and innovation is increased

The interaction among all members of the team (product side and development) added to the freedom people have in self-organized teams boosts creativity and innovation in ways that would be impossible to other approaches. Highsmith states that "one of the tenets of adaptive organization is that innovation emerges from the interaction of diverse individuals, each with it own ideas, who bring information and insight to the development process". Cockburn calls software development "a game of invention and collaboration". The interaction between produt experts and technology experts is what produces this synergy. Business experts provide the input necessary to build a product that adds value and technology experts fix the boundaries of what's possible and suggests other paths that would help create the same value.

It is important to note the difference between a waterfall approach and an agile approach in this regard. While in waterfall, all the innovation happens at the beginning, when the system is being architected and designed, in Agile there is a big leeway to innovate and create during the development process. Added to this, the change from a command and control structure to a self-organized team structure unleashes the creativity of all members (I still remember having heard at University that developers don't have to "think" much. They received the designs and just have to translate those designs into code.. Sounds easy, doesn't it?)

3. Processes are focused on delivering value

Mary and Tom Poppendieck talk about the importance of decreasing the time it takes from the moment where someone has an idea until that idea is converted to a product, something that adds value. From concept to cash.. what's in between? The Agile world has been greatly influenced by these ideas.

The ideas the Poppendiecks brought to the Agile world come from the Lean concepts that Toyota uses in their Toyota Production System (not a good moment to say so?). Lean has 7 principles, of which the first one is "Eliminate Waste". Waste is everything that doesn't add value to the final product. Eliminating waste leaves us with the useful things: the things that add value to the product. To be able to identify waste and improve the lead time, Mary suggested using a tool that is already been used in manufacturating called "Value Stream Mapping". This tool allows to visualize all the flow since a requirement is borned until it is completed, identifying the steps that add value and the ones that merely act as links. Visualizing this flow allows to think about optimizations.

These ideas are very compatible with Agile, that states that working software should go over comprehensive documentation. Working software is what produces value, is the essence. Processes and coordination mechanisms are reduced to the minimum possible to be able to produce this value. The more complex the problem, the more coordination mechanisms, formality and ceremony will be needed but under the Agile principles, it should be kept to the minimum necessary.

4. Value is delivered early

Agile delivers software incrementally. This allows to plan for intermediate releases if the project is big. If you add to this that the most valuables features are produced first, the result is an early delivery of the most important value. 

Comparing to waterfall, where all the value is delivered in the end the advantages are enormous:

- The most important problems are solved first.

- There's the possibility of putting a product in the market faster.

- Progress is measured in terms of value (i.e. in terms of a working product).
- Management can make decisions based on real progress. Their visibility is improved and the information they have to make these decisions is better.
- Partial releases means creating influx, which increases the Return on Investment.

To add to this, there are studies that show that for some systems 80% of the users use 20% percent of the functionality. Being able to delivering this 20% of the functionality provides (as you can imagine) great value.

I am deliberately leaving risk out of this point. Risk is the other factor that should be taken into account when prioritizing features. Risky features have high priority and should be attached early. It could be said that if business or technological risks cannot be overcome, the project won't be able to deliver any value (so it can be seen from the value perspective as well)

5. Value is delivered sustainably

Yeah, it is not only early delivery of value. Agile is also about being able to continue adding value to an existing product in a costly manner. The Declaration of Interdepence states that the objective is a continuous flow of value. 

Being able to deliver value for a long period of time (that's what sustainable means) requires many things in the human area, the process area and the technical area: 

On the human side, it requires a jelled team that pushes always in the same direction (even if the direction changes). It requires understanding and collaboration among members, especially between the product members and the development members. The development team needs to understands the product team decisions and the product team needs to listen to the development team. This could be particularly challenging when the direction changes too often and there is the need to do development rework because the development team could feel that the product team doesn't have a vision/objective. This is why it is very important that all members of the team at least participate in the decisions. Participatory decision making is vital to sustainability and it's vital to keep all team members committed to success. 

On the process side, it requires a light process that allows changes to be accommodated. In other words, a process that allows the team to adapt. A heavy process with a lot of formality and ceremony makes adapting difficult. Agile processes on the other side are designed to react.

On the technical side, it requires simple design, clean code and ruthless automation testing. 

    - Clean code: Design evolves, a lot of changes on the code are made continually and if the existing code is not refactored continually to accomodate all changes, it could become a mess very soon. 

    - Simple design: One of the Agile principles says "Simplicity - the art of maximizing the amount of work not done - is essential.". Ron Jeffries says "Always implement things when you actually need them, never when you just foresee that you need them." (YAGNI principle). Simple design means the team only develops code that servers a purpose. They don't try to foresee and implement features that will be needed in the future. This point could be contentious as well because a lot of people will say that to make a good OO design, we need to see the whole picture. Agile relies on evolutionary design. That is, when a new feature needs to be implemented that forces to change the design of existing ones, this should be done. Abstractions should be created at this moment and the code should be refactored. This can be done because there should be a good suite of automated tests to harness all these changes. The code needs to be clean (at the previous point said) at all times.

    - Ruthless Automated Testing: The main reason of the importance of automated tests is being able to regress the existing functionality almost continually. Automated tests provide the harness to evolve the design and to refactor the existing code without fear.   

All of these requirements aim at maintaining the cost of change low. If the cost of changing gets higher, changing is more difficult (e.g. If the code is not maintained clean or automated tests are postponed, technical debts accumulate and very rapidly delivering value becomes more difficult) and keep adding value gets difficult. In highly exploratory projects or projects with high uncertainty, this becomes specially important. In these environments, Agile methodologies are perhaps the only ones capable of delivering value.  

6. Value is the objective

As it can be seen, there is strong focus in Agile on providing value, on giving the customer what the customer needs. In fact, value is so important that Jim Highsmith suggests replacing the traditional iron triangle for one that includes value.

This is his proposition:

In the old triangle, if "scope" grows either the project will take longer (time is modified) or the cost will be higher (cost is modified). This triangle was used to take management decisions,  and to measure the success of the project. Using this triangle, a project is successful if it delivers the scope, on time and within the required budget. The new triangle has value, quality and constraints in its vertices. A successful project in the new triangle is one that delivers value with the expected quality and conforming to the constraints.

Performance measurements, processes and activities are designed to optimize value. Under Agile, a project that sticks to an outdated plan that doesn't provide any value won't be successful, even if it finishes on time and with the required cost. Processes should support the delivery of value in a sustainable way, even in changing conditions. 

Conclusion

- It is better value because the customer participates in the creation of this value. The customer has responsibility in shaping the product to fit their needs. The product is the result of the collaboration between people that know the business better and people that know how to implement the ideas. There is also more people contributing to creating the product. A group that self organizes and has freedom allows to get the value from all its members.

- Value is delivered earlier because processes and people are focused on delivering value. The most important value is delivered earlier, allowing to maximize the ROI and solve the customers problems faster. Keep adding value is possible at a reasonable cost because the cost of change is kept low.

- Finally, value is the objective. Processes exist to support the creation of value and are trimmed to the minimum necessary.