Reading time 4 min

Kris Vandebroek

Destroying complexity one Epic at a time Remember the Atari classic Asteroids? If you’re familiar with it, you might already feel a twinge of nostalgia. If not, here’s the picture: You’re in space, piloting a ship surrounded by massive, slow-moving asteroids. Easy targets, right? But every time you shoot one, it shatters into smaller, faster fragments, much harder to shoot and dodge. When you first start out, you might opt for a strategy that focuses first on shooting all the largest asteroids. They are slower and easier to hit. But, soon enough, you’re dodging tiny, chaotic rocks flying everywhere. You lose control and then 💥 BOOM! Game over. Sounds familiar? It’s a lot like losing control when managing complex projects. There is a better way! And it’s a strategy that works in software development as well as in the Asteroids game. In software development, we call it Progressive Elaboration . Breaking down big problems: the Asteroids approach to agile To reach a high score in Asteroids, you’ll want to focus on one large asteroid. You systematically break it down in smaller parts and try to clear them. This will make sure that you’ll always stay in control. The total number of asteroids flying around you, is kept to a minimum and the other large asteroids are easy to follow and avoid. When you completely eliminated the first asteroid, you can target the next big asteroid. This is also how we approach large, complex challenges in software development. When faced with multiple Epics (a large, complex problem), tackling multiple at once can lead to chaos and a high Cognitive load . By using Progressive Elaboration , we focus on one item that brings the highest value, break it down into manageable pieces (Features or User Stories) and prioritize them. Next, we can focus on the piece with the highest priority. This way, we keep everything manageable and avoid that 'Game Over'-feeling when a project spirals out of control. How to apply Progressive Elaboration: 3 techniques Here are three examples on how to start applying Progressive Elaboration — or, as we call it here, the Asteroids approach — to break down complexity and focus on delivering value: 1. User Story Mapping Use this technique ( reference card ) when you are launching a new product or a larger end-to-end service. Step 1: Map the customer journey. Define each step of the customer journey and identify all the personas involved. Step 2: List potential features. For each step, list the possible features to enable the user in that step of the customer journey. Step 3: Identify the smallest viable features. Focus on the smallest possible set of features to build towards the E2E workflow. It should either deliver value to the customer, provide insights to the Product Owner, or reduce development risks. Step 4: Target and tackle. You’ve identified the first Asteroids to focus on. Tackle them one by one, splitting them when needed until you reach User Story level. Step 5: Deliver, learn and repeat. Consistently re-evaluate, keeping the big picture in mind while breaking down and focusing on one asteroid at a time. 2. Upstream Kanban This technique is especially useful when the core E2E workflow of your product has already been implemented and the Product Team wants to improve or expand it. The Upstream Kanban board is your visualization of all the “Asteroids” that are flying around your project. At any time, we have a lot of possible features we can build. We call these “Options”. These Options must be prioritized. When the team has available capacity to start shooting the next Asteroid, it goes into “Discovery”. This is where we use the Progressive Elaboration Technique. We break the Option down into smaller parts and we prioritize. Then one by one, aligned with the priority, we can do the actual delivery (= detailed analysis and development). Step 1: Visualize “asteroids” on a Kanban board. List out the Options that the business or users would like to explore. Step 2: Prioritize Options by Value. Sort based on outcome or potential value. Step 3: Pull items when capacity allows. When ready, pull an item into Discovery—where it’s analyzed and broken down. Step 4: Move to delivery once clear. When an item is well-defined, send it downstream for development. 3. Mindmapping This technique is flexible and effective, even for smaller tasks like creating a blog post. Step 1: Use a mind mapping tool or paper. Write down the big “asteroid” you want to tackle, break it down into smaller parts, and prioritize. Step 2: Focus on one item at a time. Repeat the breakdown process until you have clear, actionable items. Step 3: Track the big picture. The mind map keeps you grounded in the larger goal while you handle immediate tasks. Keep complexity under control and deliver value By adopting these techniques, you’ll face fewer “game-over” moments in your projects. You’ll keep complexity under control, delivering value one manageable chunk at a time — just like breaking down asteroids before they overwhelm your ship. So, what’s your next big asteroid? How will you apply these techniques to make your projects more manageable and deliver more value? Are you interested in learning more? 🎁 We’re offering 5 free brainstorming sessions with an Agile Coach. Claim your spot now! And if you need a break, play a remake of the original Asteroids game here !

Reading time 10 min

Kris Vandebroek

Think about the team you’re currently working in. Are you working Agile? When I ask that question, in most cases, I either get an (over)confident “YES!” or an unsure look and a question back: “Uhm… What do you mean exactly?”. The people that responded confidently to the question above often start enumerating all the Agile Practices that they apply, be it Scrum, Kanban, retrospectives, stand-ups, demos or Test Driven Development. The hesitance of the other people mostly comes from the uncertainty of what Agile really is. When are you doing Agile? What is enough? What exactly is working Agile? Instead of seeing Agility as a rigid thing, it helps to see it as a maturity scale. Everyone and every team is working in an Agile manner, but not every team has reached the same level of maturity. Although the differences between teams or even individuals can be big, just like in Kaizen (Continuous Improvement) or Karate Belts, no one will ever reach the maximum. There’s always room for further improvement. Speaking of improvement in working Agile: applying Agile Practices will generally improve your Agility . However, to keep that level of Agility from stagnating and to really grow, you’ll need more than copying and applying Agile Practices. The key is to build-in the Continuous Improvement mindset of consistently validating your way of working by the 12 Agile Principles . Working Agile means that you continuously shape and improve your way of working by challenging it against the Agile Principles. Review your process frequently, using the Agile Principles as guidelines and the Agile Practices as inspiration! Working Agile means that you continuously shape and improve your way of working by challenging it against the Agile Principles. Review your process frequently, using the Agile Principles as guidelines and the Agile Practices as inspiration! The same is true for working Lean. It means that you continuously evaluate your workings by the 7 Principles from Lean Software Development . These 19 principles can be a bit overwhelming, so inspired by these principles, I’ve created 7 steps to increase the Agility of your IT teams. 7 steps to increase Agility for new or existing teams Think of the whole product development lifecycle for the product that you’re currently working on. It starts from the value you want to create for the customer or the assumption that you want to verify. It ends when the smallest solution for that outcome is delivered to the end customer. With that process in mind, let’s walk through 7 steps that will help you increase the Agility of your IT teams. 1. Visualize, visualize, visualize Physically visualize what your teams are working on. Visualizing creates more transparency and lowers the barrier for others to join in on discussions. A visible workflow provides a structure for your collaboration and allows for more in-depth discussions. Here’s a small subset of ways to visualize whatever your team is working on: visualize the flow of work through a physical Kanban board, using sticky notes to represent the value you’re trying to create and lanes that represent the different steps that are required. Annotate the sticky notes to make impediments visible. Add avatars to make it what everyone in the team is working on. visualize the customer journey, product scope and releases by having the User Story Map visible in the team room. Alternatively, hang up the screen mock-ups or product screenshots on the wall. Draw up the personas and list the information you have about the end-users. trigger discussions on the design of your software by having printouts of the architecture diagrams in the team space. Visualize your domain model as well to ensure that everyone speaks the same language in these discussions. understand the users by visualizing insights about your product. Which features are being used and which not? How many users are facing errors? share a common goal by visualizing the progress toward the next milestone or MVP. Any blockages in your progress, e.g. a failure in your build pipeline, should be visible on a TV screen so everyone in the team immediately gets a heads up. TIP: Next time you have a visitor, especially business stakeholders or sponsors, walk them through the visualizations in your team room. It will give them ‘Boots on the Ground’ and valuable insights about the project. It will be a boost in trust and confidence. 2. Collaboration documentation Building complex products requires multiple skills and multiple people. Instead of creating a document and handing it over to the next person the process, focus on collaboration and knowledge transfer in person. A document can be outdated quickly and require a lot of time to be kept up-to-date, while you’d rather spend resources on getting actual work done. By sharing information face-to-face or participating in the brainstorm, everyone involved in the development process gains a lot more insight and will be able to do a better, more qualitative job. Here are some ideas: Regularly walk through the software design, architecture, customer journey and domain model with the whole team. Start the development of a story with a kick-off in which the analyst explains the story and its rationale face-to-face. Don’t forget to involve your dedicated tester if you have one! Pair programming is one of the best ways to learn from each other and to get a team that is fully aligned. 3. Fast feedback Building a product is a team effort and requires a lot of work. We want to make sure that we are always doing the right thing with the right quality. The only way to know that you’re delivering valuable work is by providing – and getting – fast feedback. This feedback from the users on the features you’ve built, but also from the next person in your workflow. The faster the feedback, the smaller the chance the next person in line will be dissatisfied with the quality of work you’ve delivered before you improve. Here are a couple of ways you can build fast feedback loops: validate early mockups or rapid prototypes of the solution with the end users before starting actual development. Make it a habit in the team that everyone takes the time to play and test the product they’ve built to raise the empathy for the users. release fast and often. If you only release once a year, you’ll only know after one year whether it was worth the investment. do a technical review of every story at the end of the analysis to improve the quality of the analysis and avoid impediments during development. Also, do a technical review of every story that has been elaborated to improve the quality of the elaboration. validate the proposed architecture and consequent changes with the team to get early feedback on the feasibility. Additionally, frequently organize team retrospectives and retrospectives with the external stakeholders or collaborators to capture everyone’sfeedback on a regular basis. Use this feedback to improve your product or processes! make new features available to test users, stakeholders and the actual end users as fast as possible. Don’t forget to gather insights on how your users use the features you’ve previously built either. 4. Create a smooth workflow To get your team to work like a well-oiled machine, you must ensure a smooth flow of work. A good flow means that planned work is delivered in a short amount of time. The investment made by the organization will be a lot lower before they see the resulting revenue. To get to that point, start by making your epic and story workflow explicit and visible with a Kanban board . Next, improve it further. Here are some tips: define WIP (Work In Progress) limits for the different steps in your process. reduce the amount of ‘idling’ work by reducing the size of queues like ‘ready for development’, ‘to test’ and especially ‘waiting for deployment’. Don’t fall in the Scrum trap that your work finishes when you have implemented the story. The value is only delivered when the functionality is available in production. measure the total number of post-its that are ongoing in your flow, whether it’s a story in analysis, review, development or deployment. Is it increasing over time? apply the mantra: “Stop starting. Start finishing!” Don’t just pick up a new story for analysis or development if you can help a colleague to finish a story already in progress. swarm impediments, difficult stories or the initial project setup with the whole team. This will drastically reduce the lead time and ripple effects it would have. 5. Split work in small parts Splitting work in small parts allows your team to perform the least amount of work before actually starting to deliver functionality. Not only does this ensure a faster feedback loop, it also gives your team a feeling of accomplishment each time they finish a chunk of work. Splitting work in small parts may seem like a daunting task at first. Here’s how to break up your work: split a big road map or product into small releases or Minimal Viable Product (MVP) increments based on the value it delivers, while taking the customer journey into account. Focus on bringing the first release live before starting work on the next release. split releases or MVPs into Epics or features that you need to deliver. Focus on finishing the most important Epics before starting work on the next Epic. split Epics / functionalities into Stories that can be implemented in 2 or 3 days tops. Focus on finishing ongoing stories before starting new stories. After breaking the work down into Epics and Stories, set the priorities for the most important pieces for an MVP. This way, you always do the least amount of work to actually start delivering without missing the bigger picture. 6. Outcome output Continuously fine-tuning your way of working ensures a smooth workflow and high output. However, it’s more important to deliver the right outcome than a high output . Otherwise, you’re just spending money that the organization could’ve spent differently. So: evaluate what you’re working on. What is the value your project will deliver? focus on finishing work in progress instead of starting new work. make sure your team is finishing its work up to the point of bringing it live to the customer. All analysis work that is not yet developed, all code that has been written and is not in production, is still ‘waste’, since it doesn’t bring any value to the end users. 7. Quality simplicity Delivering quality needs to be everyone’s focus within the development process. Without that focus, you’re sure to deliver sub-optimal results to the next (or final) step in the process. Think of bugs, impediments, and confusion that end up costing more time and resources. To keep your focus optimal and avoid mishaps, always work on the simplest solution that meets the goals. A simpler solution is easier to understand, implement, explain and support. Only implement what you need now and what is in scope of the current story, spike, or epic. Any additional scope might result in work that will not be used. Every form of inefficiency in code or the way of working is technical debt that your organization will pay for eventually. Consistently remove small parts of this technical debt. By removing small parts, there is no short term negative impact on the performance of the team and you will still benefit from the mid and long term positive results. Use tooling like Sonar to review the quality of code. Make it a habit when implementing new features to reduce technical debt in the code that you are modifying. Continuous, small refactorings do not hinder the delivery of value, but a big rewrite, when the technical debt is too high, will have a huge impact. Takeaway Continuously improving the way of working using the Agile en Lean principles as the guiding stars, is still not common in every (IT) organization. This blog post gives some actionable steps you can take to increase the Agility of your IT teams. You don’t have to start implementing all these steps right away, though. Start with a few that are manageable for your and your team, evaluate, improve and repeat. That’s how you’ll increase the Agility of your IT teams in an Agile way! If you want more information, tips, guidelines or more, reach out to our Agile coaches and they’ll help you out! {% module_block module "widget_d4e6cfcb-35d2-444d-9d01-5d17f1ba509e" %}{% module_attribute "buttons" is_json="true" %}{% raw %}[{"appearance":{"link_color":"light","primary_color":"primary","secondary_color":"primary","tertiary_color":"light","tertiary_icon_accent_color":"dark","tertiary_text_color":"dark","variant":"primary"},"content":{"arrow":"right","icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"tertiary_icon":{"alt":null,"height":null,"loading":"disabled","size_type":null,"src":"","width":null},"text":"Contact our Agile coaches"},"target":{"link":{"no_follow":false,"open_in_new_tab":false,"rel":"","sponsored":false,"url":{"content_id":null,"href":"agile-coaches@aca-it.be","href_with_scheme":"mailto:agile-coaches@aca-it.be","type":"EMAIL_ADDRESS"},"user_generated_content":false}},"type":"normal"}]{% endraw %}{% end_module_attribute %}{% module_attribute "child_css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "css" is_json="true" %}{% raw %}{}{% endraw %}{% end_module_attribute %}{% module_attribute "definition_id" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "field_types" is_json="true" %}{% raw %}{"buttons":"group","styles":"group"}{% endraw %}{% end_module_attribute %}{% module_attribute "isJsModule" is_json="true" %}{% raw %}true{% endraw %}{% end_module_attribute %}{% module_attribute "label" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "module_id" is_json="true" %}{% raw %}201493994716{% endraw %}{% end_module_attribute %}{% module_attribute "path" is_json="true" %}{% raw %}"@projects/aca-group-project/aca-group-app/components/modules/ButtonGroup"{% endraw %}{% end_module_attribute %}{% module_attribute "schema_version" is_json="true" %}{% raw %}2{% endraw %}{% end_module_attribute %}{% module_attribute "smart_objects" is_json="true" %}{% raw %}null{% endraw %}{% end_module_attribute %}{% module_attribute "smart_type" is_json="true" %}{% raw %}"NOT_SMART"{% endraw %}{% end_module_attribute %}{% module_attribute "tag" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "type" is_json="true" %}{% raw %}"module"{% endraw %}{% end_module_attribute %}{% module_attribute "wrap_field_tag" is_json="true" %}{% raw %}"div"{% endraw %}{% end_module_attribute %}{% end_module_block %} Contact our Agile coaches