« An Agile Coach know more than just Scrum, » said one consultant in a boardroom meeting, « he/she knows organization dynamics, executive coaching and other Agile practices like Kanban and DevOps, » he continued.
« Stay silent, no need to correct him in this kind of forum, » my inner voice said. « Take a deep breath. »
If you’ve ever opened up a meeting invite and thought “Oh no… not one of those again”, this article is for you. And you’re not alone! While the types of meetings you’ll find at any given organization will vary, a few of the most common types are universally loathed. Others types of meetings, however, are genuinely useful and can even be a lot of fun (if you know how to do them right).
Meetings are expensive. If you don’t believe me, this meeting cost calculator is pretty convincing. Meetings should only be held when they are the cheapest and/or fastest way to accomplish a task.
With 88 percent of companies adopting low-code as a standard for developing applications and 74 percent of those companies planning to integrate business lines into the application development lifecycle, it is clear that companies are embracing this technology to relieve the pressure in application demand. And now your boss has told you that low-code development is the new way, and you need to break the news to your team.
Some of your existing developers may be skeptical about low-code, saying things like, "Low-code is beneath my skill set", "I’ve tried this before and it doesn’t work; I always end up coding anyway", or "I can code faster than this." What they often don’t realize is that low-code development makes their lives easier and aids them in achieving what they’ve always wanted, to make an impact on their organization in a fundamental way. This is the goal, right? So how can you get developers to buy into using a low-code platform?
Since March 2017, the Google Play store has published over 2.8 million Android apps for users to choose from. As for the Apple App Store, they have published over 2.2 million apps since that time.
Despite apps being used regularly by mobile users, there are not as many app downloads. As a result, there is a lot of competition to get the attention of app users. App startup entrepreneurs need to do thorough research to give their users some value and solutions to their demands. All this must be done before developing the product if they don’t want to see their startup fail
There is one of two things every company tries to do whenever they are looking at purchasing a new tool: raise the bottom line by reducing costs, or increase their top line by increasing sales. The main problem we see with people researching community software is a lack of focus in what they want the product to do, and what business objectives they want to accomplish. Before moving forward with a solution, you need to ask yourself what your goals are, and whether this tool can help you accomplish those goals.
The number one way a community can raise your bottom line and reduce support costs is through case deflection. The easiest way to measure ROI here is in how much time it takes your team to close a case if they have to deal with it at all. The goal of a community is to transition from a one-to-one or one-to-many support structure towards a many-to-many support structure. Allow your community to earn reputation, badges, and leaderboard position by solving people’s problems, resulting in you not having to hire more professional support staff when your community scales.
I hesitated as my mouth hung open a bit. A senior leader in a development organization had just asked, "Why is product important?"
We’d been discussing an evolution in thinking in our industry — the movement from being process-focused to being progress-focused and now, the need to be product-focused. He innocently asked the question as he attempted to process the idea that what we build is more important than how quickly and efficiently we build it.
As a consultant, I get to see a lot of different organizations and work with a variety of teams. By now, virtually everyone has at least heard of Agile and read the Manifesto. We also seem to have, in technology adoption terms, crossed the chasm, and so adoption by more traditional, sometimes slower moving, global scale organizations is well underway. Agile has finally been vetted by the early adopters and is now becoming mainstream.
I, like others, talk about the difference between "doing Agile" and "being agile" — differing the big "A" Agile and the little "a" agile is intentional [BC1]. From an intellectual perspective, the notion of Agile being a mindset and a different way of seeing and acting in the world rather than a methodology or a process usually resonates. Still, though, I see a tendency to want an "Agile checklist"; a tendency toward Agile for the sake of being able to say "we’re Agile" rather than genuinely zeroing in on value and excellence. I cannot tell you how many times I’ve heard, "It’s not ‘Agile’ if you aren’t doing <insert practice here>."
When I teach any sort of product/project/portfolio management, I ask, "Who believes multitasking works?" Always, at least several managers raise their hands. They believe multitasking works because they multitask all the time. Why? Because the managers have short work-time and long decision-wait time.
If you are a manager, your time for any given decision probably looks like this:
“Digital twins” are commonly associated with Industrial Internet of Things installations, in which they are widely used. They generally work as follows: the sensors from a machine are mapped to a digital abstraction, or “twin,” making it easier to monitor the machine and know when it needs maintenance. The digital twin can also be used to model the lifecycle of the machine, predicting when, for example, individual parts are likely to fail. In fact, any physical asset that is receptive to monitoring and prediction, such as a city or even the human body, could benefit from a digital twin.
But the “digital twin” as a concept can also be extended in a different direction—to non-physical modeling. One particular area where it can be effective is in managing customer relationships, i.e. tracking and accurately predicting a customer’s needs. Basically, it can enable businesses to offer “the right product at the right time.”
In an ideal world, every project is finished on time, and within the estimated budget. Even better, the budget has allowed teams to develop additional features and test everything one more time before the release. In the real world, the development process can encounter several difficulties, and technical debt is among the most common issues the project may face. It is essential to understand what technical debt is, how to evaluate it and especially how to tackle it.
Technical debt is the additional work needed to complete the software development. But this notion does not refer solely to the projects that are in development. This issue often follows the projects that have been production for some time. This may be anything, like some module written on legacy technology, that holds the project back from including a new functionality or influence overall software stability. In this particular case, technical debt can be calculated as the time or money needed for the refactoring of this module’s code or porting it to the new technology. But usually it is never that simple and the software system includes a number of drawbacks that can be included in the technical debt of the project.
