Agile in the core

Author: Arie van Bennekum

1   Fact

Agile has grown and matured. It is not a trend anymore. We can say Agile has established more or less. Nevertheless we see companies struggling to make it really work. The last 5 to 8 years I often get questions from organizations to check in and look at the way they work. Their trigger is the struggle with Agile and making it successful. During those years I have drawn to the conclusion that it is not Agile causing the problems but the way people apply Agile techniques.

Those techniques are what I started calling Agile in the Core about 5 years ago. I registered the URL and the brand. In 2014 I started with Johan Lybaert, at that time managing director of Cegeka’ s Agile international software factory, an international coaching team of highly skilled people called as such. Members of this team are not only knowledgeable and experienced in Agile, they are also specialists in human behaviour and they understand how to change organizational systems to implement Agile successfully. Agile in the Core is in everything we do when we work at the client site.

Those techniques are what I started calling Agile in the Core about 5 years ago. I registered the URL and the brand. In 2014 I started with Johan Lybaert, at that time managing director of Cegeka’ s Agile international software factory, an international coaching team of highly skilled people called as such. Members of this team are not only knowledgeable and experienced in Agile, they are also specialists in human behaviour and they understand how to change organizational systems to implement Agile successfully. Agile in the Core is in everything we do when we work at the client site.

2   Agile in the Core

In 1994 I got stuck in the way I had to work. Stuck in a way I had to make a choice in life. Either it was for me working in a different way or I had to a move into a different professional domain. I chose the first one, helped by one of the business developers at that time. I entered the way of working based on Rapid Application Development. My journey of continuously innovating had begun. When I started working the “different way” in 1994 I was consciously fighting 4 problems:

• We often deliver stuff (solutions) the business does not really need.
  I have been in situations where end-users really refused to use an evolved solution simply because they could demonstrate it was not helping them or even worse. On top of this history repeats itself all the time. Big projects are often stopped half way because they are heading in no direction still these days.
• We often deliver stuff (solutions) with a lot of hindering errors.
  Too often the quality of products, and especially software solutions, is so poor organizations are disrupted frequently in their daily operations. Some of them even get to the front page of newspapers…
• We often deliver over time.
  Delivering late is so common people take this as a standard even these days. Delivering late is not only causing irritation, the most important problem is the delayed Return on Investment. This ROI can be up to a level it puts an organization out of business before you know it.
• We often deliver over budget.
  Another problem we see frequently. In the Netherlands there was a year average of 189% in 2012…

 

For me there are very basic issues behind those problems:

• We often deliver stuff (solutions) the business does not really need.
  When you do deliver but it does not meet business needs, communication with the business representatives is clearly not at the required level or in the required way. Somehow in between expressing needs and delivering the solution we have created communication pitfalls we step in over and over again. So we have to fix communication.
• We often deliver stuff (solutions) with a lot of hindering errors.
  The old joke about software solutions is you get the bugs for free and you have to pay to get them fixed. Point is software professionals know how to deliver quality so the real question is, “what the *&*% is going on?” For me the problem is discipline. Under pressure people start doing things in a different way than agreed and known. So we have to fix discipline.
• We often deliver over time.
  Over and over again we make estimates and we are not able to meet dates, market demands and business needs in the time scale. When you deliver late you have to accept you are damaging your business. Delaying means late (or not at all) ROI and that can become a serious problem. So we have to fix the late time to market.
• We often deliver over budget.
  It is a matter of efficiency and finding a way of working with estimates and reality in a harmonized way. On top of this we have to find a way to handle the alien, the infamous “Request for change”. New insights, changes, latest developments, etc. come in all the time and are being put on top of the original plan. Projects tend to grow; once I wrote an article where I called this “project obese”. So we have to fix the project obese.

 

On top of this we have more. Over time 2 demands have become more opportune. First of all, because of technology we have an enormously increased pace of innovation. This innovation not only facilitates the creation of new types of products and solutions, it also facilitates globalisation and therefor the competition in the market. These 2 developments have impact on how you have to look at products.

• Products/solutions have a much shorter time to market.
  It is simple, when you are not able to deliver on time, the competition will. We all know the stories of big and well known multinationals who lost their position in months or just a few years. Simply because they were not able to deliver. We see them in the professional domains of publishing, telecommunication, high tech mobile industry, etc. So we have to increase our time-to-market.
• Products have a much shorter product life cycle these days.
  That is a fact. Before you know it products come and go. And not only products or solutions, even for example law-changes have a faster pace than we were used to. When you know the product life cycle the need for perfection has no use anymore. It is the value that counts. So we have to focus on the value instead of requirements.

 

Finally there is one more thing we have to accept.

First of all, we, the world we live in and the products and solutions we need are often not that simple. In the traditional world we are used to define things up front. When solutions are complex (complex is often defined as not clear what all goes in and the outcome cannot be predicted) and the environment is constantly changing, you have to admit that detail definition up front is impossible. When this is impossible, exploration has to be part of the development. So, implement exploration in your development process.

 

• We often deliver stuff (solutions) the business does not really need.
  I have been in situations where end-users really refused to use an evolved solution simply because they could demonstrate it was not helping them or even worse. On top of this history repeats itself all the time. Big projects are often stopped half way because there heading in no direction still these days.
• We often deliver stuff (solutions) with a lot of hindering errors.
  Too often the quality of products, and especially software solutions, is so poor organizations are disrupted frequently in their daily operations. Some of them even get to the front page of news papers…
• We often deliver over time.
  Delivering late is so common people take this as a standard even these days. Delivering late is not only causing irritation, the most important problem is the delayed Return on Investment. This ROI can be up to a level it puts and organization out of business before you know it.
• We often deliver over budget.
  Another problem we see frequently. In the Netherlands there was a year average of 189% in 2012…

For me there are very basic issues behind those problems:

• We often deliver stuff (solutions) the business does not really need.
  When you do deliver but it does not meet business needs, communication with the business representatives is clearly not at the required level or in the required way. Somehow in between expressing needs and delivering the solution we have created communication pitfalls we step in over and over again. So we have to fix communication.
• We often deliver stuff (solutions) with a lot of hindering errors.
  The old joke about software solutions is you get the bugs for free and you have to pay to get them fixed. Point is software professionals know how to deliver quality so the real questions is, “what the *&*% is going on?”. For me the problem is discipline. Under pressure people start doing things in a different way then agreed and known. So we have to fix discipline.
• We often deliver over time.
  Over and over again we make estimates and we are not able to meet dates, market demands and business needs in the time scale. When you deliver late you have to accept you are damaging your business. Delaying means late (or not at all) ROI and that can become a serious problem. So we have to fix being the late time to market.
• We often deliver over budget.
  It is a matter of efficiency and finding a way of working with estimates and reality in a harmonized way. On top of this we have to find away to handle the alien, the infamous “Request for change”. New insights, changes, latest developments, etc. come in all the time and are being put on top of the original plan. Projects tend to grow so often I wrote an article one I called “project obese”. So we have to fix the project obese.

On top is this we have more. Over time 2 demands have become more opportune. First of all, because of technology we have an enormously increased pace of innovation. This innovation not only facilitates the creation of new types of products and solutions, it also facilitates globalisation and therefor the competition in the market. These 2 developments have impact on how you have to look at products.

• Products/solutions have a much shorter time to market.
  It is simple, when you are not able to deliver on time, the competition will. We all know the stories of big and well known multinationals who lost their position in months or just a few years. Simply because they were not able to deliver. We see them in the professional domains of publishing, tele communication, high tech mobile industry, etc. So we have to increase your time-to-market
• Products have these days much shorter product life cycles.
  That is a fact. Before you know it products come and go. And not only products or solutions, even for example law-changes have a faster pace then we were used to. When you know the product life cycle the need for perfection has no use anymore. It is the value that counts. So we have to focus on the value in stead of requirements.

Finally there is one more thing we have to accept.

First of all, we, the world we live in and the products and solutions we need are often not that simple. In the traditional world we are used to define things up front. When solutions are complex (complex is often defined as not clear what all goes in and the outcome can not predicted) and the environment is constantly changing, you have to admit that detail definition up front is impossible. When this is impossible, exploration has to be part of the development. So, implement exploration in your development process.

ble, exploration has to be part of the development. So, implement exploration in your development process.

3   Agile in the Core

Communication issues, delay, lack of discipline and lack of focus. Those are the issues to focus on and the traditional way, waterfall or whatever you call it does not work. First of all the sequence, second the processes, third the handover and fourth the perception of change have to be adapted all to modern times in an ever changing and demanding environment.

1. Basically Foundations is the starting point for discipline and focus on value. Main part of Agile is about being efficient in developing value. The question which has to be answered before you can do this is WHY we are developing, HOW we are developing and how we will WORK together during development? This is what I call Foundations. The WHY is regarding the SMART objectives for this project. Full delivery working means also delivering the real business value. To be able to do this you need to know them very clear. This HOW is regarding techniques to be used for these product/solutions. This will impact estimates, people needed, etc. The WORKing agreement is very important to be aligned with all involved on how to work as a team. The Foundations originate from DSDM. It was already present in the first version in 1995 but officially got its name some years later. Very effective for focus, an absolute MUST for high quality delivery and matching business needs. So Foundations help you set the best communication environment for the project.

2. Heart beat.
   One thing I know is the fact that traditional ways of working often mean working in silos. Silos mean most of the time different professional groups/domains including their process for taking into their workload and transferring it to the next group. During this processes over and over again we see interpretations, assumptions and estimates passing by. I call those 3 a triplet sharing the same DNA. What they share is simply that they are wrong and unfortunately we perceive them as the truth.
   So we have included already a lot of errors and on top of this the process takes a lot of time, is based on documents sent by mail and maybe explained once or twice.
   Also the original source of the initial info often is not involved anymore or is doomed to work with documents in a “strange language”. We have to bridge this gap. The answer is bringing all involved (not just “business and IT”) together in one rhythm.
   The heartbeat is the answer. It takes away the process delay and takes care of (when well facilitated) the language differences. In a heartbeat session all stakeholders (where stakeholder is defined as anyone/anything who/which has a say in the shape and/or functionality of the solution/product). Why all these entities? Because they can (and will) cause delay somewhere in the end-to-end process and they can stop going to the next phase because they have an authority. During initial work (see Foundations) and development we have weekly or at the most 2 weekly a facilitated workshop where we focus on the content of the solution. We can adjust, adapt, refine, prototype, validate, verify and create business value all in one during this session. Basically this heartbeat session fixes the communication issues.

3. I often hear people say “Agile and all those meetings…”. To be honest, to me dailies and heartbeats are the only “meetings” we have. All the other activities are contributing to development. Where the heartbeat is about the content of the project, the daily is about the process of the project. Daily’s well done and supported with the right visuals, will give you an almost real-time insight in the production process of the team. In DSDM they were introduced as daily achievement meetings and I seriously like that phrase. It tells you exactly what we need to know, what we achieved, or not and if not what happened. When problems arise, of any kind, the team can take it on right away. There will be no delay, no “student syndrome”. Decisions can be made, solutions can be addressed and priorities can be set during the delay wich all helps the team to maintain speed. So basically the daily helps you to fix your time to market.

4. Common language/visualisation.
   There is confusion in the world. Often documentation is mistaken to be a synonym to MS-Word or MS-Excel and it is not. For me documentation is registered information which can easily be retrieved and re-used, updated, etc. When we say we bring stakeholders together we already see a lot of moments where we can skip documentation as we are used to. When information stays documented in the team space we can switch to visualisation on the wall. Most people know by now the plan board and I would like to recommend visuals for architecture, clearly defined user groups, story maps, project progress reporting, Foundations, etc. It is easier to access, easier to update, easier to use and they are also a common language.
   So visualisation fixes the communication by creating a common language. Also it creates a shorter time to market because we can maximize the work not done and focus on development.

5. One of the things we know is the fact we don’t think in details. We often work on complex solutions or products to help us in complex situations. It is impossible to design in detail up front so we have to explore during development. This exploration is an activity done by the team, all included and the communication gap has to be bridged. The common language mentioned above can be extended by using prototypes. The prototype helps you to explore, based on a common language with the advantage to be able to validate if we are all on the same page and verify if we are still delivering the right requirements. So prototyping helps you to focus on value, have an additional common language and implements exploration in the communication process.

6. Integrated testing.
   All activities done in the sequence only at the end are a potential risk. When something goes wrong at that moment we lose our time-to-market, we destroy business value, we create project obese and discipline is endangered. Testing, and any other form of check on the materials, at the end of the development process of a whole period of time therefore is an unwanted phenomena. Testing, in any form, should be an integrated activity. Integrating means you do it all the time, on all aspects and, very important, on the smallest piece of work with business value in the sprint or time box. This way you are always able to deliver some requirements and what you deliver has got all the attention needed to deliver good quality. So integrated testing helps you to fix the discipline and fixes the time-to-market.

7. Frequent delivery.
   Projects (or work in the operational line) are meant to create business benefits. So the sooner you deliver them, the sooner you create those benefits; the business value. Basically you say, the sooner the better. If so you have to look for the smallest time scale for delivering new value. In my personal environment we all work in 2 week time boxes but that is just a guideline. The other side is that either people think they need longer timeframes to deliver anything of value or they somehow keep parts of the sequence as mentioned above alive. Doing full delivery, all activities needed to do what has to be done in the time box is essential. You have to think twice in deciding what to take into the time box (so you choose the ones delivering the most value and requiring the least of work). You strive for the shortest time scale and business will be helped at the earliest stage possible. So the frequent delivery helps you to focus on value and increases your time-to-market.

8. (de-)Selecting requirements and minimizing work in progress.
   During development new insights emerge, existing requirements evolve and new requirements might come in. As said, we can’t predict the future so we have to explore. The changing set of requirements is part of this. Going through the old-fashioned RFC-procedure we encounter 2 problems. First this process takes time, weeks are more or less the standard, and when you want to deliver every couple of weeks this destroys the entire process. Second the team is waiting for the decision which might impact the other requirements. And third the only people who really know how to help the SMART objectives are not on the Change advisory board but in the team. Minimizing the work in progress ensures you finish materials in every time box. No other work is needed because all the work has been done; no more extra work or costs afterwards. So basically (de-)selecting requirements helps you to overcome project obese.

9. Regarding documentation already some things are solved with information radiators. Another related issue is code ownership. Too often parts of code have been developed by one developer and the other developers do not really know (or not know at all) this code. It causes delay in fixes and embeds the risk of tunnel vision. Teams and organizations try to overcome this risk by creating very comprehensive documentation. This documentation very often (unfortunately) is inaccessible and (often) difficult to read. Using the technique of pair programming, code is easily shared, better code is developed and there is code ownership at team level. It helps to really solve fixes must faster. Of course people ask about the fact that it seems that 2 are doing the work of one. Statistics however show that pair programmers are much more effective and efficient in developing code. In the initial project approximately 10-15% extra time is needed. For this you get better quality, better business value and we maximize the work not done (less documentation). So pairing helps you to fix the discipline and improve your communication.

Looking back we can see Agile is a true interaction concept. It is all about bringing the right people together, at the right time, talking the right way about the right things. The essence of the interaction is that you take the sequential process, turn it 90 degrees and have all stake holders together in a shared rhythm with sessions for the process and content of the work to be delivered.

 

4 Target audience

Agile can be applied in any professional domain. As long as you are able to work within the values and the principles of the manifesto you will get the benefits you are looking for. Agile can be and has been applied in multiple professional domains (like IT, infrastructure, health care, HRM, marketing, communication, education) and I don’t mean within their IT-department.

5 Scope and constraints

Benefits working Agile:

• You have a swifter return on investment because of a shorter time to market;
• It provides a better return on investment because of the flexibility during development;
• It leads to cheaper development because of the better focus on WHAT (size) to deliver and HOW to deliver (process);
• It is cheaper during operations because of more robust products as a result of better development practices.

 

In general Agile:

• Gives you the benefits when you work within its values and principles;
• Is an interaction concept, not a method;
• Can be adapted to the needs of an organization, using a combination of methods; pick what you can use as long as you stay within the values and the principles of the manifesto;
• Involves a number of paradigm shifts that can be problematic for people to accept. This causes the real problem in applying Agile in the Core and is a threat to Agile success.

 

Application of Agile:

• It works well in every environment, when you simply stick to its values and principles;
• It is supported by tooling, both in the end-to-end development process (such as testing, building and deploying) and team process (to cross geographical distance in team communication);
• Works well in every professional domain. It has been implemented in areas like health care, marketing, product development, etc. There are no exceptions.

 

6   Relevant websites

www.agileinthecore.com

www.cegeka.com

www.agileconsortium.net

www.agilemanifesto.org

www.dsdm.org