In this article, we'll go through the basics of Hotwire and build a sample app using it.

The widely adopted SCM tools we use today, GitHub and Gitlab, are built on the dated architecture and design of git, but this has some security gaps we'll explore.

Healthcare organizations must join forces and invest resources to develop a global digital transformation strategy and adopt digitalization standards.

In order to leverage observability, we need a significant shift in our corporate culture that encapsulates the entire company and goes beyond the tools.

In this tutorial, learn how to update and reload your SSL configuration whenever needed without restarting your server or recreating your HTTP client.

Growing usage of location-based services requires investment to build an ecosystem of trust and transparency with users and service providers. Learn more here.

Continue on a journey into the world of cloud-native observability: go out onto the playing field to understand who the players are and what teams they form.

Accessibility Test mainly focuses on making the website or app usage accessible to folks with Auditory, Visual, Cognitive, Motor, and Speech Disabilities.

Explore the difference between two well-known Auth building methods: AWS Cognito and JSON Web Token. Plus, take a look at the AWS Cognito application process.

Check out the benefits of deploying a service mesh, popular tools for deploying a Service Mesh, and more here in this article.

One of the best ways to tighten your Kubernetes security is by implementing ten tactics that have become industry standard.

Agile - What’s a Manager to Do? As a manager, when I first started learning about Agile development, I was confused by the fuzzy way that Agile teams and projects are managed (or manage themselves), and frustrated and disappointed by the negative attitude towards managers and management in general. Attempts to reconcile project management and Agile haven't answered these concerns. The PMI-ACP does a good job of making sure that you understand Agile principles and methods (mostly Scrum and XP with some Kanban and Lean), but is surprisingly vague about what an Agile project manager is or does. Even a book like the Software Project Manager’s Bridge to Agility, intended to help bridge PMI's project management practices and Agile, fails to come up with a meaningful job for managers or project managers in an Agile world. In Scrum (which is what most people mean when they say Agile today), there is no place for project managers at all: responsibilities for management are spread across the Product Owner, the Scrum Master and the development team. We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems. In Scrum, we have removed the project manager. The Product Owner, or customer, provides just-in-time planning by telling the development team what is needed, as often as every month. The development team manages itself, turning as much of what the product owner wants into usable product as possible. The result is high productivity, creativity, and engaged customers. We have replaced the project manager with the Scrum Master, who manages the process and helps the project and organization transition to agile practices. Ken Schwaber, Agility and PMI, 2011 Project Managers have the choice of becoming a Scrum Master (if they can accept a servant leader role and learn to be an effective Agile coach – and if the team will accept them) or a Product Owner (if they have deep enough domain knowledge and other skills), or find another job somewhere else. Project Manager as Product Owner The Product Owner is command-and-control position responsible for the “what” part of a development project. It's a big job. The Product Owner owns the definition of what needs to be built, decides what gets done and in what order, approves changes to scope and makes scope / schedule / cost trade-offs, and decides when work is done. The Product Owner manages and represents the business stakeholders, and makes sure that business needs are met. The Product Owner replaces the project manager as the person most responsible for the success of the project (“the one throat to choke”). But they don’t control the team’s work, the technical details of who does the work or how. That’s decided by the team. Some project managers may have the domain knowledge and business experience, the analytical skills and the connections in the customer organization to meet the requirements of this role. But it’s also likely to be played by an absentee business manager or sponsor, backed up by a customer proxy, a business analyst or someone else on the team without real responsibility or authority in the organization, creating potentially serious project risks and management problems. Some organizations have tried to solve this by sharing the role across two people: a project manager and a business analyst, working together to handle all of the Product Owner’s responsibilities. Project Manager as Scrum Master It seems like the most natural path for a project manager is to become the team’s Scrum Master, although there is a lot of disagreement over whether a project manager can be effective – and accepted – as a Scrum Master, whether they will accept the changes in responsibilities and authority, and be willing to change how they work with the team and the rest of the organization. The Scrum Master is a “process owner” and coach, not a project manager. They help the team – and the Product Owner – understand how to work in an Agile process framework, what their roles and responsibilities are, set up and guide the meetings and reviews, and coach team members through change and conflict. The Scrum Master works a servant leader, a (nice) process cop, a secretary and a gofer. Somebody who supports the team and the Product Owner, “carries food and water” for them, tries to protect them from the world outside of the project and helps them solve problems. But the Scrum Master has no direct authority over the project or the team and does not make decisions for them, because Agile teams are supposed to be self-directing, self-organizing and self-managing. Of course that’s not how things start off. Any group of people must work their way through Tuckman’s 4 stages of team development: Forming-Storming-Norming-Performing. It’s only when they reach the last stage that a group can effectively manage themselves. In the mean time, somebody (the Scrum Master / Coach) has to help the team make decisions that they aren’t ready to make on their own. It can take a long time for a team to reach this point, for people to learn to trust each other – and the organization – enough. And it may not last long, before something outside of the team’s control sets them back: a key person leaving or joining the team, a change in leadership, a shock to the project like a major change in direction or cuts to the budget. Then they need to be led back to a high performing state again. Coaching the team and helping them out can be a full-time job in the beginning. After the team has got together and learned the process? Not so much. Which is why the Scrum Master is sometimes played part-time by a developer or sometimes even rotated between people on the development team. But even when the team is performing at a high level, there’s more to managing an Agile project than setting up meetings, buying pizza and trying to stay out of the way. I've come to understand that Agile doesn't make a manager’s job go away. If anything, it expands it. Managing Upfront First, there’s all of the work that has to be done upfront at the start of a project – before Iteration Zero. Identifying stakeholders. Securing the charter. Negotiating the project budget and contract terms. Understanding and navigating the organization’s bureaucracy. Figuring out governance and compliance requirements and constraints, what the PMO needs. Working with HR, line managers and functional managers to put the team together, finding and hiring good people, getting space for them to work in and the tools that they need to work with. Lining up partners and suppliers and contractors. Contracting and licensing and other legal stuff. >/p> The Product Owner might do some of this work - but they can't do it all. Managing Up and Out Then there’s the work that needs to be managed outside of the team. Agile development is insular, insulated and inward-looking. The team is protected from the world outside so they can focus on building features together. But the world outside is too important to ignore. Every development project involves more than designing and building software – often much more than the work of development itself. Every project, even a small project, has dependencies and hand-offs that need to be coordinated with other teams in other places, with other projects, with specialists outside of the team, with customers and partners and suppliers. There is forward planning that needs to be done, setting and tracking drop-dead dates, defining and maintaining interfaces and integration points and landing zones. Agile teams move and respond to change quickly. These changes can have impacts outside of the team, on the customer, other teams and other projects, other parts of the organization, suppliers and partners. You can try using a Scrum of Scrums to coordinate with other Agile teams up to a point, but somebody still has to keep track of dependencies and changes and delays and orchestrate the hand-offs. Depending on the contracting model and your compliance or governance environment, formal change control may not go away either, at least not for material changes. Even if the Product Owner and the team are happy, somebody still has to take care of the paperwork to stay onside of regulatory traceability requirements and to stay within contract terms. There are a lot of people who need to know what’s going on in a project outside of the development team – especially in big projects in big organizations. Communicating outwards, to people outside of the team and outside of the company. Communicating upwards to management and sponsors, keeping them informed and keeping them onside. Task boards and burn downs and big visible charts on the wall might work fine for the team, but upper management and the PMO and other stakeholders need a lot more, they need to understand development status in the overall context of the project or program or business change initiative. And there’s cost management and procurement. Forecasting and tracking and managing costs, especially costs outside of development labor costs. Contracts and licensing need to be taken care of. Stuff needs to be bought. Bills need to be paid. Managing Risks Scrum done right (with XP engineering practices carefully sewed in) can be effective in containing many common software development risks: scope, schedule, requirements specification, technical risks. But there are other risks that still need to be managed, risks that come from outside of the team: program risks, political risks, partner risks and other logistical risks, integration risks, data quality risks, operational risks, security risks, financial risks, legal risks, strategic risks. Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management. Ken Schwaber While the team and the Product Owner and Scrum Master are focused on prioritizing and delivering features and resolving technical issues, somebody has to look further out for risks, bring them up to the team, and manage the risks that aren't under the team’s control. Managing the End Game And just like at the start of a project, when the project nears the end game, somebody needs to take care of final approvals and contractual acceptance, coordinate integration with other systems and with customers and partners, data setup and cleansing and conversion, documentation and training. Setting up the operations infrastructure, the facilities and hardware and connectivity, the people and processes and tools needed to run the system. Setting up a support capability. Packaging and deployment, roll out planning and roll back planning, the hand-off to the customer or to ops, community building and marketing and whatever else is required for a successful launch. Never mind helping make whatever changes are required to business workflows and business processes that may be required with the new system. Project Management doesn't go away in Agile There are lots of management problems that need to be taken care of in any project. Agile spreads some management responsibilities around and down to the team, but doesn’t make management problems go away. Projects can’t scale, teams can’t succeed, unless somebody – a project manager or the PMO or someone else with the authority and skills required – takes care of them.

In my previous post, “3 Reasons Why Knowledge Worker Engagement Is Decreasing”, I discussed the increasing pressure on organizations, the changing nature of work, and different reasons why employee engagement and thereby also productivity and innovation are eroding, especially in large and distributed organizations. I grouped these into three overall themes: complexity, inflexibility, and disconnectedness. Now what can an organization do to reverse this negative trend? It could strive for the opposite, of course, towards increased simplicity, flexibility and connectedness. Here are 9 things your organization can do to get moving in the right direction. Simplicity 1. Adopt a user-centric approach Study after study shows that people-centric organizations are more productive and profitable, and that being people-centric is a mindset that is instrumental to building a high-performing organization. This applies to all aspects of an organization, not the least information technology. Instead of leaving the people out of the equation, information technology must be designed in a way that it extends people’s abilities and senses, allowing them to make the most out of their collective expertise, talent and engagement. We are seeing this happen on the commercial web, but it is yet to be seen at work. The solution should be obvious: you need to adopt the thinking, approaches and methods that are used when designing customer experiences and use it when designing the internal work environment. 2. Simplify interaction between people In a knowledge-intense work environment where the work people do is highly inter-dependent, you need to reduce the complexity in the interactions between people. It requires you to study these interactions in detail - why they are needed, when, who interact, what they lead to - so that you can identify typical interactions and then simplify those interactions. Key in this is to understand the people, their tasks and the situations they find themselves in. Ultimately our digital work environment should be invisible, helping us achieve our goals without any friction at all. 3. Make it easy to perform basic tasks Most knowledge workers still struggle with basic tasks on a daily basis, many of which are not creating value. Therefore, you need to make it much easier to perform those tasks. Although the tasks of knowledge workers come in all shapes and sizes, many of them rely on a number of basic capabilities, such as finding information or locating expertise. By improving these capabilities, your organization can empower its employees to perform their tasks more efficiently and effectively. By removing waste and friction on task and capability level, you will also be able to see substantial improvement when all these small improvements are aggregated on process, departmental, and enterprise levels. Flexibility 4. Embrace flexible working Research shows that what employees of all age groups want is the flexibility to determine for themselves where, when, and how they work, and that increasing workplace flexibility has a positive effect on employee engagement and thereby also on employee productivity. Your organizations need to support this, not only to increase efficiency by reducing lead times by enabling people to do their work when it needs to get done, but also to make people more engaged at work and thus more productive. 5. Support mobile working New mobile technologies enable you to get your work done anywhere, at any time, with anyone. The tools and information you need to get work done can now be made available to you anywhere and anytime. Yet your organization's culture, management practices, performance systems, organizational structures and priorities are keeping you from exploiting this opportunity to the fullest. Therefore you identify necessary changes and implement those so that mobile working is truly supported. 6. Make it easy to perform tasks in different situations Your digital work environment should follow us wherever you go, helping you to get your work done, in different situations. This means that you will need digital services that are designed to fit typical situations. These services should all be tied together in a coherent user experience, providing access to all information you might need, allowing you to work seamlessly together with your colleagues from anywhere. You will need to establish a shared vision, strategy and governance model for the entire digital workplace. Connectedness 7. Connect people Achieving operational excellence today and tomorrow starts with having the right people on board and then connecting them to each other. With better connections, your organization can solve problems and act upon opportunities in a fraction of the usual time. And it can achieve it fewer resources and by activating underutilized resources such as expertise hidden in distant corners of the enterprise. When people become more connected, they will feel more engaged. They will be able to build their personal networks and access the social capital they need to get their work done. So, you will need to provide systems in place that allow people to connect and use those connections. 8. Embrace social principles Your work environment needs to be designed according to the principles that make people engaged and empowered to be more productive and innovative. There are five principles in particular that should guide the design of your organization and work environment: Openness. People need openness to get access to information and other resources they might need to get their work done. Transparency. People need transparency to be able to find and discover the information and resources, and to trust it. Participation. Anyone needs to be able to participate, because that’s how we can deal with any kind of problem or opportunity. Conversation. If people can have conversations it will increase the likelihood that their communication is effective, allowing them to quickly can reach mutual understanding and take the necessary actions. Recognition. People need to be recognized for their contributions if they are to remain motivated and continue contributing. 9. Create an open and transparent work environment To avoid sub-optimization and other negative effects of organizational silos, you will need to create a more open and transparent work environment, one where you can see and interact with your colleagues within and across organizations. You need to increase visibility of people, information and other resources. You will also need to create mechanisms that allow people to find and discover relevant people and information, without drowning in a rising sea of information. Once you have created a more open and transparent environment, people can start making themselves visible, participate and engage in constructive conversations. Doing so, they will discover new people with similar interests, experiences and goals. They will connect, get to know and build trust in each other. When they do, when they feel connected and feel part of a community, cooperation and collaboration happens naturally. Not because someone tells them to, but because they want to. At the end of the day, it is about creating the necessary conditions for employees to become engaged and empowered to do their jobs as good as possible. Remove all friction. Love synergy, hate waste.

Some great links about technical debt: Technical Debt - from metaphor to theory and practice (presentation) Special IEEE Explore issue on Technical Debt (Nov 2012) Must read if you're passionate about quality and have seen or heard some of the issues mentioned in these materials.

Anton Oparienko (COO at Upsilon) shares insights about the importance of the discovery phase for software development projects and gives expert tips.

Let's dive into The State of Value Stream Management Report 2022 and its lessons for software and platform engineering teams.

Software engineering is much more than coding skills.

Take a look at this latest Daniel Stori comic to see what happens when you click the mouse and just do it.

Kubernetes monitoring helps to identify problems within a Kubernetes cluster. Know more about Kubernetes monitoring and why it is important here in this blog!

CDK has landed, and the AWS community is hyped, but what exactly is CDK, how it works, and what does it mean for the world of Infrastructure-as-Code?