Many organizations are transitioning to Agile as their preferred lifecycle model for software development. Transitions were directed due to inability for former methods to lead to successful results. After being brought in to help manage a portfolio of projects in several organizations, there were some disturbing trends when using Agile:
- Software was delivered, but the users found the software to be unusable.
- Consultants developed the software, then left. The organization staff had no idea how to maintain the software.
- A number of application projects were completed. Each had a different architecture and set of tools required to build and maintain the application.
- Projects were being reported to governance teams with scheduled dates, yet there were no apparent requirements, use cases, user stories, backlog or other lists that might indicate what is being built.
- Management was completely at a loss about how to resource projects since many seemed to be ongoing forever without completion.
There were some exceptions; however, the preponderance of software development initiatives that succeeded were very small in scope and constituted a low percentage of overall projects required for customers. There was some information available within the organizations that indicated a process was initiated to convert from a traditional (Waterfall) lifecycle to the Agile lifecycle. Many of the benefits of Agile, however, were not being demonstrated by the activity taking place. What happened?
Read More Are you Agile, or Fragile?
Development does not happen on one single platform in today’s environment. Microsoft .NET has evolved in the last two decades to allow for a full cross platform development. Microsoft has introduced .NET Core to its .NET ecosystem, a fork from existing .Net Framework to develop a new framework that is very much portable across various platforms.
Applications targeting .NET Core can easily run on Windows, Linus and macOS, at the same time Microsoft is committed to keep as an open source platform model. Microsoft .NET Core framework should not be viewed as a replacement to .NET framework. Applications using Windows Presentation Foundation (WPF), Workflow Foundation (WF), Windows Forms and other libraries not currently supported by .Net core will continue to use .NET Framework.
Read More .NET Core and Microservices, an Introduction
Myth: The Scrum Master is just another way of saying Project Manager
Not only do both roles do completely different things, but generally a Project Manager has a hierarchical role above the team, something that is not true of a Scrum Master.
Myth: The Scrum Master is the leader of the Scrum Team
The Scrum Master is not a Project Manager and does not have a higher role than the Scrum Team than the rest of the team. This is a common myth that can lead to disaster when adopting Scrum. It is human nature to look for someone to lead a group. Scrum teams are self-managed and decide how they are going to work and what rules (in addition to those imposed by Scrum) will be established.
Read More Myths about the role of the Scrum Master