LATEST NEWS
Leadership Reflexions

Agile Dev: No one wins unless everyone wins.

Blog Article

We are going AGILE...

There are some of those days when things change. I remember the days I was “cool”. And then the other day I needed to “chill” (you can guess my age with that info!).

So, one day, we heard it for the first time in the office: “We need to be way more agile. We need to work better.”

Words have meaning, but sometimes words don’t hint target straight as they should. Entering a transformative journey for an organization requires more than words. It requires from leaders intense communication, training, and sharing moments. People are not scared of change, but they might be concerned to see disappear something they like or think is important. By listening and discussing, we go beyond words, and we understand what needs to be done.

Here is a journey of me understanding what AGILE is. 

DAY 1: Agile?

Agile, adjective

1. quick and well-coordinated in movement:
an agile leap.
2. active; lively:
an agile person.
3. marked by an ability to think quickly; mentally acute or aware:
She's 95 and still very agile.

So back to that day, I was excited! We needed to think and move quickly. We needed to be fast, lively, smiling and shining. I felt like an acrobat already! And I think we all did! 

At the coffee machine, there was even more excitement, … and questions: “Aren’t we already quick and coordinating with everybody? Do we need to do it more elegantly?”

It really felt at first like the “flower phenomenon” (and for a couple of months more). The flower phenomenon is an example to illustrate that sometimes we use the wrong expressions to communicate our ideas. If someone ask for a flower, that person might be surprised when they receive one. Did it mean a rose, a tulip, or any of the other hundreds option out there?

That feeling lasted for some days, and months… until i could come up with my own definition.

 

What is AGILE anyway (my take on it!)?

First, Agile is not an adjective. It is not a characteristic of something we already do. 

It is a noun. It is a thing on its own. 

It is a way to develop software, but it is more then that! (I don’t want to be thrown to the crocodiles as a sacrifice to the God-of-Agile). It is a way to develop software that will influence behaviors of an organisation if applied and lived to its fullest.

 In terms of a digital product, it is about having:

  1. less code, 
  2. fewer dependencies, 
  3. fewer bugs and problems, 
  4. fewer wait times, 
  5. to create more value.

It is a way of working, where everybody thinks as a team what is best to do with a finite (opposite of infinite) number of hours, money, and resources to dedicate on a project. Yep, we should be carefull of those elements even in a big company.

 

 

The analogy to a house

The best way I found to explain Agile development is to think about various strategies for buying a house. Everyone dreams about having a big house (the massive software with 1000 features). I mean, the house with many rooms, the workshop, the garage, the greenhouse, the trampoline by the tree. 

We are sometimes conditioned to think that this is what we need and that the only way to get there is to save money for a big transaction. Or, we need to get a loan at the bank, tying ourselves to that transaction for years further. This big house can become hard to maintain, and risky to acquire if you are unsure you’ll like it.

A safer move, everyone would agree on, is to start with the minimum viable part of that house: the main building, with a bathroom, a kitchen, and some rooms. Start with what is just needed. Even if it is hard at times to decide, start with what is absolutely needed. 

Then of course, if it is a success, if you like it, if you have cash flow, expansions can be designed to fulfill different needs. 

The trick with this strategy is that you offer yourself different loops to define your needs. You might have thought once that a big TV room was a must, but maybe you have picked up your guitar at some point and realize you would be best suited with a home music studio.

At the end of the day, you have not lost time and money to build something you don’t need, time and money to unbuild it before you spend more time and more money on something else.

Features are defined by designers as solutions to problems. We need these features because we believe they fulfill the needs of our users. If our house is a piece of software, we could imagine for the purpose of the example that some elements of the house are developed for some reasons:

Productivity, the main building

Users need to achieve a lot of tasks. Something that would make them solve the same tasks faster would appeal to them. 

This could be the core values of the software. For example, without an increase in productivity, users would never adopt the software. 

Usability, the playground

Users need to have fun using a specific tool. Something that would be simple and intuitive would appeal to them.

This could easily become a principle, and could not even be a feature. It could just mean: do things always simple and nice.

Learnability, the home additions

Users need to learn a specific set of skills while using the software. The more they can learn, the more the software would appeal to them.

This is important set of features, but it can also be described as incremental improvements. Learnability has depth. We can develop something that enables small learnability and develop more after.

Accuracy, the end of the yard

It is great to know where your project ends, where the neighbours are, where not to go. 

Some features could look important at first, but maybe they are not after a second thought.

Of course, land acquisition for expansion is always possible, but reaching that point would mean that everything on your own turf is going well.

The case of the content editor

The waterfall way

Here is an example that illustrate where developing in a non-Agile way can lead.

The example is taken from the software development process of LEGO Education Mindstorms EV3. In particular, a specific feature that we have called the content editor.

The needs were identified to be productivity and usability. We knew that students and teachers could not follow a lesson flow if the information is located outside of the software (usability). We also knew that a lot of teachers are creating their own content using various tools such as PowerPoint or even Google Presentations (productivity). So it was decided to develop a full embedded editor inside the software. The tool needed to care for:
  • text
  • images
  • building instructions
  • video
  • sounds
  • webcam
  • PDF
Basically, we needed to develop an editor on its own, or in other words, recreate Microsoft Powerpoint.
The tool ended up being not used, as it was harder to understand than tools teachers were already using.

The Aglie way

The agile way could lead to a different story. 

Before scoping the Software Requirements, a small prototype could have been made using Microsoft Powerpoint and by embedding these presentations inside the alpha software. At that time, it could have shown if the teachers would have used that way of doing things. 

If this strategy would have shown to be not effective (we are now pretty sure it would have proven to be really powerful!), we could have started building something else blocks by blocks, maybe by starting with text and images and expanding from there. 

Agile, also a communication strategy

Learnings from the content editor project

At the end of the day, Agile development is an amazing way to break down a big problem into smaller parts. It offers a rich framework to use when making decisions and when explaining to stakeholders.

For the process to work, it requires a high level of communication between teams (hence all the techniques and tools developed to implement it).

However they work, team leaders and team members need to communicate in such details to reach a deep common understanding of what and how to do.

Communication is about getting feedback in, making sure that all data is valid and that it can guide our next sprint.

In other words, using Agile development should allow everyone to internalize the fact that if there is a way to create more value using less code while having fewer dependencies, fewer bugs, and problems, and fewer wait times, we should go for that.

If you read only this

Using Agile development should allow everyone to internalize the fact that if there is a way to create more value using less code while having fewer dependencies, fewer bugs and problems, and fewer wait times, we should go for that.