Scrum is simple, but Scrum is Hard. Scrum is so simple that it can be explained in 20 minutes, but so hard that some teams are never effective. Yet other teams produce 3-10 times more business value than they did before. This article will go into one of the main differences between under-performing teams and very successful teams— Code Quality—and its impact on the effectiveness of every Scrum team. You will learn how to present the business case for high quality code, how to facilitate the establishment of a business commitment to high quality code, and how to implement the process of transforming code quality to an enabler rather than a restrainer of the delivery of business value within your organization.
Technical Software Product Specification
In a Complex Regulatory or Standards Based Domain
Agile and it's various implementations, including Scrum, while most often discussed in software development circles, can correctly be classified as Product Development methodologies. Most of the time the product being developed has software as a major component, but they are products developed to solve a problem or make a job easier or more efficient. When we think about products in this broader context we can often identify some impacts on product management rooted in the Agile practices and thought process. We need to understand these impacts to be prepared to mitigate them and propel the organization to the next level.
How much of the new course will be coding vs. project managment and testing?
According to Mike Vincent on his blog (http://mvasoftware.com/blogs/mikev_weblog/default.aspx) the launch date for VS/TFS 2010 has been set for March 22,2010. You can also check out Mike's article that lists the product features for each version of Visual Studio 2010
. Check out our new course on Scrum Using VS/TFS 2010
I'm sure that you all know the story of how the term "bug" got associated with a computer failure. It was a moth in a computer which caused a hardware failure. However, since then the term bug has become synonymous with a software error. There is a bug in the program. Yes, there is a bug in the program, every program. Many software development organizations spend a large portion of their time and effort finding and fixing bugs. However the situation rarely improves. hbrfj8e3c4
As a ScrumMaster and Agile Coach, I develop the same feeling about the team's work environment. Depending on the team the "room tone" will be different and in iterative development the tone will be different depending on the stage of the iteration the team is in.
I’m a white board and sticky type of agilest. Give me a team room with white boards and a bunch of multicolored stickys and I’m a happy camper! Why? Because I know that the white board and stickys are NOT the project, the people and the conversations they have with each other are the project and the white boards and stickys are used to drive those conversations and track the work. However for most teams and most organizations, my agile dream project just does not exist and trying to force it to be is foolishness. Most organizations are going to need a tool to manage the project and provide visibility
There is a lot of information out there about why an organization would attempt to improve their software development process using any of the wide variety of methodologies, techniques, systems, coaches and mentors that market their message. In fact there is so much information it is overwhelming to anyone genuinely trying to improve their process. I've been out in the trenches for several years now and have seen many different approaches used with varying degrees of success. In fact no two organizations have ever done the same thing or had the same results.
Driving a software project to deliver later is just plain wrong!