The financial processes of companies can defeat their own efforts to become more agile. It’s simply impossible for an organization to be adaptable if their project processes require all projects to be specified up-front and funded months ahead of their starting date.
Tackling the financial process changes in our organizations is one of the make-or-break aspects of helping organizations become Agile and adaptable.
In this episode, we talk about Lean and Agile Financial Planning (PDF article download), an approach that tries to adopt Agile and Lean thinking in the funding and financial processes of an organization.
The reason why Lean and Agile Financial planning is a core aspect of Agile transformation in enterprises
I am a big believer in continuous improvement, weather that be in the form of Retrospectives, a Kaizen approach, or something else that helps the team reflect regularly. But for the earlier years of my career as a Scrum Master I found myself frustrated by a lack of improvement despite all this reflection (retrospectives that have no impact…).
Often,what I was seeing was that we talked about the problems the team was facing, and then didn’t follow-through with the actions we agreed to take.
When we tried to change our behavior. We might have succeeded for a day or two and then would forget about it. This isn’t continuous improvement this is just continuous discussion!
We need a good way to make sure we are actually making the change we set out to make!
We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:
Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.
Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.
This is the story of one such retrospective.
Obviously, you can perform many Agile practices, but not be Agile. However, there are a lot of practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.
In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also color coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.
With over 50 cards, there was a lot of information. We split into groups and started categorizing the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.
Doing (Working Well): Things we are currently doing, and quite happy with the way they currently work.
Doing (Could be better): Things we are currently practicing but could use improvement.
Not doing (By choice): Things we are not currently practicing, but have made a choice not to use in our context.
Not doing (Not tried): Things we are not doing, and have never really tried.
WTF!?!: We have no idea what this is, or what it means.
Deciding what to focus on
We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:
We should start and or alter this practice in some way. (Indicated by a dot)
We would like to learn more about this practice. (Indicated by a +)
I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.
Discussions and action points
We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:
Root Cause Analysis/ 5 Why’s
We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might reveal something we would have otherwise been unaware of.
Experiments: 1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand-ups, then we should also consider doing a more in-depth analysis of those items.
Discussion: We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.
Experiments: 1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.
Behaviour Driven Development (BDD):
Discussion: This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.
Experiments: 1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.
This retrospective was reviewed well by the team, everyone generally liked it.
It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.
Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future, we would probably recommend only focusing on these things.
There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully, a bit cheaper for you, as we have provided the work we have done. Once again: https://tinyurl.com/l8loec6
It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list beforehand.
Despite there being so many items, the list was not even close to exhaustive, and it was hard to leave off some practices that really should have been included.
Jeff is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life and considers helping others to improve their working life not to simply be a job, but a social responsibility. As an Agile Coach, he has worked with driving Agile transformations in organizations both small and large.
Jeff is also involved in the Agile community and is one of the founding members of Gothenburg Sweden’s largest agile community at 1500+ members , and he also organizes the yearly conference www.brewingagile.org.
Scrum Masters understand the importance of having many tools for different situations. The quality of our work is often related to the quality of the tools we have in our toolbox and the context in which they work.
Tim was faced with a problem. How to be a leader without any formal power. All Scrum Masters and Product Owners who have felt the responsibility, but not any “line authority” have faced the same problem. You need to help move the project along, but you can’t tell people what to do!
In this episode we explore the concept of Lateral Leadership how it can help you as a Scrum Master or Product Owner.
In this Bonus episode, Gunther introduces an approach that he has developed over the years, to help companies that are struggling with Scrum in particular or Agile in general. But before that, we have a very interactive conversation about some key questions for Scrum Masters and Agile Coaches.
The biggest struggles in Agile Adoption
We start by reviewing some of the biggest and most common struggles that companies face when adopting Agile. In this question, we not only review the most common obstacles, but we also tackle the true origin of Scrum and Agile. Why it is there, and what are the promises of this way of working that get forgotten in many of the Agile adoptions in the world. Scrum, specifically was created to improve the quality of the workplaces where it is used. But is that idea followed in practice?
The biggest obstacles to successful Scrum Adoption
Many organizations start from the point of view that Scrum is a way for teams to work. That is far from the truth, according to Gunther. Scrum is a whole organization way of working, with the PO (product Owner) role being an example of a role that transcends the team focus and works with the whole organization to help create an understanding of value that ultimately gets translated into the team’s work backlog. Gunther points to the biggest silo of them all, as an example of how we misunderstand Scrum: the silo between “business” and IT.
Removing the obstacles to successful Scrum Adoption
How do we remove obstacles to the successful adoption of Scrum? With a specific approach to Scrum adoption that Gunther shares with us. This is an approach that he has developed over the years and reflects the patterns of successful adoption he’s seen. He calls this approach the “Scrum Zone”.
Reversify your organization with Scrum, after you’ve solved the major obstacles
Once the major obstacles to adoption are overcome, we then need to understand where to take Scrum in our organizations to make it a core productive engine for our businesses. This is what Gunther calls “Reversify, re-imagining your organization”: make it a productive engine, a core of value production that aligns the whole organization. This is an approach that Gunther has been developing over the last few years and shares with us in this unique BONUS episode about the future of Scrum.
During this episode we mention several resources. Here’s a list for your reference.
Gunther left consulting in 2013 to partner with Ken Schwaber, Scrum co-creator, at Scrum.org. He represented Ken and Scrum.org in Europe. Gunther left Scrum.org in 2016 to continue his journey of Scrum as an independent Scrum Caretaker.
He calls himself a connector, writer, speaker, humaniser. Gunther assists, serves, advices teams, individuals and executives.
Gunther believes that Scrum – the most applied software development framework – will not only increase the value that software delivers to organizations but is also a way to re-humanise the workplace for people. Gunther likes to inspire individuals, teams, departments, and organizations to realize their potential.
Beyond Scrum, Gunther is all about his family, life, books, and music. He communicates in Dutch and in English. Gunther is co-creator to Agility Path and the Nexus framework for Scaled Professional Scrum.