Everyone nowadays is using a form of agile. Whether it’s to manage your IT-backlog or to use it for change management, a form of agile has probably already been implemented at you company. However, there is a downside to it. Let’s discuss a short take on agile, the challenges and what it can contribute
Why use agile?
If you look at the agile manifesto rules Principles behind the Agile Manifesto you will see that it has a kind of ’10 commandments’ guidance on what you want to do. It it focusses on striving for excellence through simplicity. To attain maximum value, maximum work done and all through autonomy and cooperation. Fair enough seems like something that can work in the western hemisphere. Then you get to the actual implementation into your organization. Wow, we feel your pain… Let’s look at Scrum.
Scrum aligns to core agile values in several ways:
- it involves an iterative, incremental development process
- it focuses on frequent delivery of working product features to the customer
- it depends on a high level of customer involvement throughout the development process, and
- it relies on self-organizing and cross-functional development teams
Unlike plan-driven development, where all aspects are defined at the beginning of the project, Scrum projects can proceed with even a high-level product backlog. Instead of defining every aspect of a product at the start of the project, a Scrum team follows a continuous cycle of inspection and adaptation. Great. You don’t want to be an oil tanker that cannot change it’s course and will get stuck in some Canal. Scrum can really add value in this way that, when you have contact with your customers, insight in usage and enough IT that can do the work, you can adapt quickly (legacy systems not counted). You can get the best value for your customer and do experimentation.
A nice example of this could be the way of working with the Coin framework. It mainly describes enough buy-in for experimentation and innovation, but it stil depics a nice way how you can get your moonshot going.
Want to know more about agile or do you want to have a assessment of what could done better. Feel free to reach out to us.
Beware; Scrum becoming a Waterfall
If anyone says that scrum or agile implementations are simple they probably don’t have any actual experience with it. Just like any other form of organizational set-ups you need to cope with a lot of uncertainty, considerations from every moving part (employees, budget, customers, or the well known people, product, process). Often when developing something within a existing organization you have to have multiple scrum teams work together to develop a single app or feature within a (web)app. You then have to make sure everything is aligned and all conditions to go-live are met.
One of the principles is that you have autonomous teams. Not easy to direct and steer. You have to get alignment. You could do this with big room plannings or with scrum-of-scrums. However, you are then basically making a loosly coupled chain of deliverables that have to align. When you get asynchronous timelines you will get a roadmap that will start from ‘Q1 going to…Q1’. In the end may reach a point of no return and you will just have to continue untill everyone is done performing their part. What it tends to go towards is alignment that looks like the traditional ‘waterfall approach’.
With waterfall you try to get as much certainty as possible upfront:
- Gather and document requirements
- Design
- Code and unit test
- Perform system testing
- Perform user acceptance testing (UAT)
- Fix any issues
- Deliver the finished product
This is often planned using a Product Requirement Document. This is often criticized from the point of view of agile lovers since it will cost too much time to have everything exactly planned en predefined. It would take away from the flexibility. However, it can become a part of agile waterfall. Where you have the PRD as a requirements document, but you can keep updating it. When you have a basic standard of what you want to achieve, how you want to achieve it and what the necessary metrics are to score against you have a better understand of what you want to aim for. When you then start developing the next increment you can take it as a reference point and centrally store all decisions being made. This can be done with a business process, but it can also take the form of a solution intent when you are talking about architectural aspects. In the end when you have finished your minimum lovable product defined in your PRD, you might go back to a more simple context and you can use scrum for smaller increments.
Has this blog sparked you interest? We could write a book about this, but it might be better just to have a chat with you… way more agile. Reach out to robbert@coduce.nl
