Category Archives: Scrum
After talking with different people, I have been reflecting about the situation where many companies seems to adopt agile techniques to be able to deliver faster and with higher quality (more gas for the same buck), but it seems like they are not driving more agility into the organization or into the products. They are not able to rapidly respond to the many emerging opportunities. It seems like the balance is more on delivering the expected and planned requirements rather than regular inspection of each completed Increment, collaboration with customers and be able to rapidly make changes and optimize business value.
Program Managers or Product Owners should do more than just deliver the approved project or approved requirements. Maximizing the business value and optimizing TCO (Total Cost of Ownership), are areas that to often are not done in most organizations. Recently I have talked with different business people who think a best practice is to have a Product Owner for a team doing support and hotfixes and another Product Owner for another team working on the new release for the same product (often called a new project). They had not considered the whole value stream of activities and how they were combined. Having a Product Owner responsible for the product, TCO and full value stream, seems like an alien thought in many larger organizations.
We need to change the sub optimizing thinking to enable Agility in organizations and move beyond the predictability mindset.
Frankly speaking, it did not expect Microsoft and TFS releases adopting agility and starting a journey on continuous delivery. I heard about MSFT people that talked about the radical change from previously doing development in 1 year followed by stabilization in 1 year to now be able to release every 3rd week to TFS as a Service on TFSpreview.com. I look forward to follow how this will evolve in the future including the pricing model and integration with Azure.
Imagine the new opportunities for many Enterprise system, if they move into a regular deployment of functional based releases to a hosted solution, and also be able to deliver their product as a service to customers. This could help them respond rapidly to customer feedback and opportunities and deliver much higher business value.
At the TFS Erfa group meeting at Microsoft Denmark in Hellerup, Rasmus Selsmark and Kim Carlsen from ScanJour presented highlights from TechEd 2012 (Amsterdam). Rasmus also did a very impressing demo using tfspreview.com to create a new TFS project with a web solution and linking it together with deployment to a Azure. Done in less than 20 minutes and then ready for continuous deployment to the production site running at Azure.
It looks like there are many opportunities for both startup companies and larger companies using tfspreview and Azure.
Rasmus has blogged more about TechEd 2012 on rasmus.selsmark.dk.
Rune Abrahamsson from BRFKredit talked about CUITe (Coded UI Test enhanced) Framework and how they have used it. It will be interesting to see how CUITe will evolve in the future.
Ole Rich Henningsen did a short demo of the new Scrum 2.0 template in TFS 2012 and it looks interesting and easy to use.
Many team and organizations are talking about doing Scrum.
The Scrum Guide describes the basic rules of Scrum and it actually only takes 9 questions to answer if your are doing Scrum or not.
If you can answer yes to all of the 9 questions, you are doing Scrum. Great. Many teams are doing some of them and still creates great software.
Still, Scrum can be played in so many different ways depending on context, the organization, products, projects etc. and Scrum can help you be more Agile. It can help creating Agility in the organizations to rapidly respond to new opportunities from customers and create emerging solutions with much higher business value. This also requires the Product Owner to think more on business value and Agility.
Based on my experience, many teams have challenges to do question no. 7 “Create a usable and potential releasable Increment every Sprint”. It requires a good infrastructure, good test automation and the Scrum Team working very well together as one synchronized unit sharing a strong Definition Of Done. Not trying to do too much, but doing what the whole team is capable of delivering. If not doing no. 7, the Product Owner can not rapidly respond to new opportunities and changes.
At ScrumForum.dk events in Marts 2012 I did a presentation about Scrum and Agile in a Distributed setup. Find the Prezi presentation below.
Some years ago I made the picture with the “Right Thing” and the “Right Way” to describe to focus and role for the ScrumMaster and Product Owner. The Product Owner must focus on what to work on and make sure the Team are working on the Right Thing in the best possible order where the ScrumMaster must focus on how things are being worked on to make sure it is the best possible way.
I have often seen this to be difficult, because traditionally it is used to be handled only by the Project Manager. Now it is split between two different roles (people). During the last couple of years I have especially seen this challenge in hybrid setup with more focus on traditional project management mixed with different agile practices. In a number of different organizations I have worked with teams (and projects), where the there is a project manager, who is trying to make sure the right thing is done in the right way. Very often with the result of more waterfall driven process either focusing on the right thing OR the right way. Most often it is in the red area in the picture. If they try to adopt Scrum, they often have a large gab in Product Owner role and need skills to be developed in this area.
The picture shows the 4 different scenarios:
1. Slow Failure
When both the ScrumMaster and Product Owner are doing a bad job, the wrong thing will be implemented in the wrong way with the result of “Slow Failure”. It will take some time to see this problem in the organization.
2. Shore Term Success
A good Product Owner making sure the right thing is being worked on by the Team, but it is not being done in the right way (ScrumMaster). In this scenario I have often seen technical debt increasing when not considering areas like agile architecture and implementing features too fast.
3. Fast Failure
Focus on using the Scrum framework and by doing this, many problems with is uncovered. In this scenario, there is a limitation in the Product Owner role to make sure the team is working on the right thing. I have seen this scenario with many new Scrum teams, where there is no one to fulfill the Product Owner role. It is a painful state to be in for a longer time.
4. Long Term Success
In this scenario the Product Owner is making sure the team is working on the right thing and the ScrumMaster is making sure it is done the right way. This is the most ideal setup for the team that can focus on making deliveries high value and with long term success. I hope this will be the most common scenarios for Scrum team in the future.
Based on my practical experience, I think we are getting better on the way of working (ScrumMaster), but the Product Owner role is still a weak area.
Why can’t we get better on making sure we are working on the right thing?