In a series of meetups, we will try to cover highlights of what to focus on if you are in the beginning of an Agile transformation. The first meetup yesterday was an “Introduction to the Agile mindset”
In case you was not able to join the session you can read more about the talking points below.
What is Agile Mindset
Too often we hear about business managers with limited Agile understanding wanting to become Agile. If you start asking why? – What do you want to achieve? – What problems do you expect to solve by becoming Agile, sadly too often there are no good answers?
Some unfortunately see Agile as this silver bullet being the solution to everything, so they begin their Agile journey, with no clear goal of what to achieve and without full understanding of what Agile really is. This is doomed to fail. We need to understand what we would like to achieve and why. We need purpose.
First and foremost, we need to understand what “Agile” is. The dictionary will tell you that “agile” is an adjective meaning “the ability to move quickly and easily” – but how does that relate to (software-) development and businesses? – Well, if you look up “business agility” we get at hint. Wikipedia says that business agility is “The ability of an organization to rapidly adapt to market and environmental changes in productive and cost-effective ways”.
This sounds great, but why is that so important?
Reality is that our world is changing. The business world has become increasingly uncertain. It has become a VUCA world – a volatile uncertain complex and ambitious world. There are always new startups challenging your domain, or excising competitors who find an advantage to take over. If you as a business stand still in this world you will most certainly lose your advantage and extinct. I think we are all familiar with the stories of Blockbuster and Kodak. You need to be able to manage and navigate in this world, and this is where agility is important.
More traditional project management processes and/or frameworks like waterfall, assumes that the future is understood and predictable. Given a well-defined set of inputs we can assume that we continuously will get the same output, so if we follow a pre-determined plan we will get the expected and known result. In other words, if we spend enough time analyzing and designing we expect that there will be no surprises down the road – and we assume that the world stands still while we do this, so what was decided as required, needed and valuable when we began the project will still be when we deliver, even when talking about projects running for multiple years. That might have been true once, but it most certainly isn’t any longer.
In the 90’s more and more IT projects where failing for various reasons, so some smart people decided a change where needed. In 2001 they met with each other to “uncover better ways of developing software by doing it and helping others do it”. The result was the today well-known Agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
You can read the manifesto and the 12 principles here: https://agilemanifesto.org/
This manifesto has been the foundation for Agility ever since and is still as of today very relevant.
Due to the success of Agile in the IT industry other industries started to look at Agile as well. They were facing similar challenges, so the solution might be the same? But how does the Agile manifesto fit into a non-IT industry? The truth is that it only does partially. Furthermore, things have also started to change within the IT industry so perhaps it is time for an updated version of the Agile manifesto? – The answer to that was delivered by Joshua Kerievsky when he introduced “Modern Agile”.
To quote himself:
“Modern Agile is a community for people interested in uncovering better ways of getting awesome results. It leverages wisdom from many industries, is principle driven and framework free.”
Joshua Kerievsky
You can read more about Modern Agile here: http://modernagile.org/
Both the Agile Manifesto and Modern Agile wasn’t something “entirely new” when written. Both build on already known tools, processes, frameworks and practices. This means that Agile can easily work together with other frameworks. For an example Agile has a lot of similar thoughts as in Lean, and can also easily be combined with Design Thinking.
Often when I ask people what Agile is I hear words like Scrum, Sprints, SAFe, JIRA, Backlog etc. It is important to understand that neither of these are Agile by themselves – they are tools that can support you in being Agile if used correct! – If used wrong they won’t help at all, and might actually be a blocker for your Agile transformation.
Agile is a mindset, an approach to your development, a way of thinking, and a way of being. These mentioned tools can help you doing Agile, but if you are not being Agile, if you are still having a non-Agile mindset, it might not matter what you are doing.
In our next meetup we will talk much more about Agile processes and frameworks that can support your Agile transformation and your Agile mindset.
So, to summarize; what would I answer if someone asked me what Agile is? – I think it would be something like:
“An approach to development where requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their end users – and adaptive planning, evolutionary development, early delivery, and continual improvement is valued while rapid and flexible response to change is encouraged”.
That’s a long answer with a lot of words – but Agile in is simplicity is very complex.
Agile Myth busting
When talking about Agile, as mentioned before, sometimes it seems like there is a believe that Agile is a silver bullet that can fix everything. There is a lot of misunderstood myths about Agile. In the session we tried to bust some of these myths. Here are a few examples:
In Agile you don’t write any documentation
This isn’t true. Documentation can be very valuable. Yes, the Agile Manifesto says “Working software over comprehensive documentation” but remember it also says “while there is value in the items on the right, we value the items on the left more” – meaning that we value working software more than documentation, but there is still value in documentation itself.
Every time we write documentation we should question the value – if it’s valuable continue. If not, then stop. We should never write documentation for the sake of documenting.
When being agile you don’t plan
This isn’t true. In Agile planning is necessary as well. We will not be running blind. But we should create our plans knowing that they will change as we progress and as the world around us change – and we will welcome these changes because they mean we have learned something. So, a plan will always be nothing but a snapshot of what we know today and this might change tomorrow.
Teams are self-managed in Agile so we have no need for managers in an Agile organization
False! Self-managed teams mean that the team has complete freedom to decide how it works and how it will implement the value required – it doesn’t mean they can decide everything on their own.
Organizational standards and policies, as well as the maturity level of the team, will put guard-rails on what a team is allowed to do. More mature teams may be given more authority than less mature teams, but even for the most mature teams, every organization has some rules that everyone must follow.
Managers are still required, but their role might change along with the Agile transformation.
Agile leaders are primarily serving leaders who help their teams improve by supporting good Agile working practices and, most importantly, interceding on their behalf when they need help to remove impediments.
A result of becoming Agile is cost reduction?
Not entirely true. An Agile approach enables teams to build and deliver a product and get feedback so that they can adapt the product based on that feedback in order to deliver more value. Not building features that have no value, and improving practices based on feedback may reduce cost as well.
So, cost reduction may become a secondary benefit, but reducing cost should not be viewed as a benefit of using an Agile approach, in fact increasing cost may be of greater benefit if the team is delivering higher value products.
A Truly agile team can change focus / direction all the time?
No! – No teams or individuals can change focus / switch context without a cost. All changes come with a cost. In Agile we try to minimize this cost. If we use SCRUM as an example, changing requirements in the middle of a sprint will be expensive but changing before a sprint is on the other hand very cheap. As long as we are aware of this cost and the value exceeds this cost, we should accept the change.
While trying to ask our team to work on multiple things at the same time it is important to be aware of the cost of context switching. Information from “Quality Software Management: Systems Thinking” says that if a person has to balance between two projects, only 2x 40% of his or her time will go to the projects. The remaining 20% of time will be wasted due to context switching – and if there are 5 projects up to 80% of time will be wasted on context switching and only the remaining 20% will be time spend on the actual projects.
The value of Agile
So, at this point you might wonder where is the value of Agile. I think there are many benefits, especially when looking at the softer values like team spirit, ownership, customer collaboration etc., but if you look at it from a business perspective I think the answers are; higher visibility and adaptability earlier business value and lower project risks.
Continuous delivering running software creates a high level of transparency for the entire organization including customers and users. Compared to more traditional development where nothing where delivered until the end, or at least not very often. This transparence give us a better tool to safely navigate the project.
Building your software incremental and evolutionary will make it cheaper to make changes during the project compared to traditional development. It won’t be cost free but much cheaper.
In Agile development the goal is to deliver value after every iteration, and we always start with the most valuable items. This results in value being materialized much earlier in the project.
When talking about deliveries we are not talking about a demo or a prototype, but a potentially shippable increment meaning that if the customer/client see value in it, it should be possible to deploy the increment to production. So even if the product is still far from feature complete users might start gaining value very early in the project and not only after the final delivery.
Finally, the early and continuous delivery of running software forces the team to address the full stack of the delivery very early on in the project – and by then address the project risks early on as well.
Risks will not be less in an Agile project, but addressing them early on enables the team to mitigate the consequences.
The Presentation
The presentation form the meetup is available on Slideshare:
Next Session
In the second session the focus will be quick introductions to different agile processes and frameworks. The focus will be on how they individually support the agile values, and not so much a detailed presentation of each.
You can read more about our Meetups on our Meetup page: https://www.meetup.com/AgileME-Dubai/
Join our Slack Channel
If you would like to be part of our Agile network in Dubai, please join our Slack channel