When talking about agile practices, the distinction between projects and products often comes up. The idea is that the limited lifespan of projects tends to be pushed onto the delivery team, which leads to the team being assembled at the onset and dismantled when the project completes. Agile practitioners advocate for a product view, where teams are dedicated to a specific product and deliver incremental value at a regular cadence, across initiative lifespans. This usually works really well, and I too favour a similar way of working in most cases. However, I have recently seen various examples of this idea being misinterpreted, which creates a situation in which teams struggle, largely due to their setup.
Continuous improvement is at the heart of any agile approach. But where do we start? And how can we know that our improvement initiatives are moving the needle? This blog post expands on the ideas from what throughput can tell you about your team and provides some additional thoughts to help you truly embrace the following principle from the agile manifesto:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
Well-designed metrics provide your team with insight into where to focus and look for improvement opportunities. They also provide you with a baseline, a measuring stick to assess any improvements.
In a previous post, I focused on what we can learn from a metric as simple as throughput. Here we take it a step further.
Let’s talk about the elephant in the room. Most transformations do not deliver upon their intended results. Many of these transformations use sound agile methodologies, yet they fail to deliver on the expected results. DevOps came along and refocused the effort, but still, we run into difficulty with transformations stalling or even failing.
Current thinking puts the development (aka. delivery) team front and center in the transformation to rapidly enable the delivery of value to customers. For a team, they need to be able to have all the right skills and capabilities at the disposal so they can own their delivery processes. In complex environments with multiple architectural principles at play, this can be difficult to achieve. To cope with this, we create another team, the platform team, to enable the delivery team.
The question is, do I need a platform team?
How many of you have been through something labelled as a digital transformation in the past 5 years? Many hands go up, and several people groan. It seems like we are in a constant state of transformation, which is true. Change is the new normal and transformation is the grandiose title given to the work we build around it.
Yet many transformation efforts stall or even fail. We encounter many reasons for this, including market pressure, hierarchy and blame culture. Even gut instinct being the primary way to make decisions comes into play! Core to most digital transformation efforts is aligning technology to business goals, which often creates problems with delivering the desired change due to their different goals.
When technology departments drive the transformation, they often need help explaining the value. Ensuring stability to reduce rework through innovative techniques and tools may not resonate. Still, we do require change through transformation for our businesses to thrive. With...
We rarely find the time to invest in personal development when we are heads down in our work and lives. Often it only occurs when a situation where something outside of our control frees up time. Even then, it takes an effort to invest in our personal development. However, it is you. You who always wanted to improve but never found time or resources to do it. It is you who has this opportunity to invest in your future today!
With the economy having slowed to a point where many organizations either have to fire staff or find them not fully occupied, this is the perfect moment to invest in that improvement there never was time for previously. Perhaps this is the time for your teams to be engaged in a program x-raying your delivery process, identifying initiatives that will set you apart from the competition, and enabling you to come out of this crisis ahead.
Often when we first engage with organizations, we find they enter the conversation with a clear idea of what their problems are. Sometimes they get it right and other times - more often in my experience - they are focusing on their own belief of where the problem lies.
For example, if the problem is the deployment process, why does the automated script take 5 minutes to run. Having successfully worked with development teams to automate deployments of their major platforms, being told deployment is the issue seems like the wrong place to focus. If it still takes weeks to get code into production, the problem lies elsewhere. Perhaps our test verification takes five weeks?
Ok. Well, if deployment of code isn’t the issue and testing is, let’s focus there I hear the cry! Well, let’s see…
Today I want to talk about a common digital transformation topic I get asked about, application modernization. More specifically, how everyone is doing it but so few successfully. Typically the conversation starts with one of the following:
“I need to move off my legacy system, how can I use containers to do this?”
“How do we move to a cloud-native microservice architecture?”
“We’ve been told to move everything to the cloud, how do we do that with thousands of applications?”
Often, my initial answer is another question: “Out of curiosity, how did you get to this as your solution?”
Strangely, at that point, it often falls off the rails.
I’ll answer these questions in more specifically at the end, today though I want to talk about complexity and the need to experiment.
One of the biggest problems here is that these are all solutions looking for a problem. While we hope they may be appropriate solutions, hope is not a strategy. On their own, there is not enough information to provide guidance an...