The 15th episode of 5 Minutes with @NYIke focuses on the modernized role of the scrum master.
The role needs recasting. Ten years ago, scrum masters were the experts on agile methodologies and charged to coach teams through the process. That's still needed for newly formed teams or to help new employees/teammates that have never been on scrum teams before. But today, many people working on agile teams and with scrum probably have some experience with it already.
Can Java development teams have all the benefits of working with their development environment and also have the speed to market, best practices, and scalability coming from a low-code platform? The answer is yes, but it requires a Java-based low-code platform that has two-way code integration into the Eclipse IDE and supports UI, workflow, and API development. And now, there’s one platform that meets these requirements and enables technology leaders to accelerate their digital transformation, improve user experiences, and modernize applications.
How leaders work with their colleagues and teams over the next few weeks can make or break innovations, capabilities, and business impacts over the next 3-9 months.
As a leader, you have to look for the inflection points when you can have teams' attention and where you can shift gears to higher faster ones. The week or two after Labor Day is one of those points, as is the first couple of weeks in January. Leaders can also create their own inflection points by communicating pivots to their digital transformation strategies.
As I said in my last post, digital transformation is not a 9-5 job, and at some point, leaders must see their teams listen, respond, plan, and accelerate. So the question I've been asked often is, how do you get a culture that's used to operating slowly and raising the speed bumps, to one that's pushing the gas pedal a little harder to meet business goals?
It's the last week of summer, so maybe take some time to reflect on your team's performance over the last several months. Has your team come up for air after adjusting to COVID, remote working, and realigning digital transformation priorities?
Because before diving into the end of year budgeting, planning, and moving transformation programs forward, I want to share and important realization. Your staff knows this all too well, but leaders often forget this fact:
It's called science for a reason. Data science requires questions, hypotheses, discovery, analysis, and recalibration. While the words I'm using to describe a data science are different than software development, the process and mindset are very applicable to agile methodologies.
And just like software development, data science requires a multi-disciplinary team. Data science is not just about the machine learning models and data visualizations, it must also include all the dataops and proactive data governance to cement an end to end journey.
I've learned the hard way that using the word automation to describe an initiative, project, process, or algorithm is a bad idea. Equating automation with artificial intelligence is even worse. Anchoring a digital transformation on initiatives driven by automations completely misses the point.
In this post, I'm going to explain why you should avoid calling it automation, or at least, what some of the pitfalls are if you do describe the work you're doing as automation.
First, here is a bit of perspective. IT has been automating work for decades. Your data integrations are at least partially automated unless all you have is an SFTP folder and then perform all the steps to load databases manually. Who does that?
Let's recap 2020 without losing our minds.
We went into the year with high aspirations around our digital transformation programs and all the places we wanted our organizations to succeed with experiences, analytics, and technology.
