The Agile Enterprise

I stumbled over the question When did scrum stop being a methodology? while working on the webinar about the role of the PMO in the Agile Enterprise. Very interesting topic because the role of the PMO is to define the project delivery processes for the organisation. My experience with Agile frameworks and PMO is that Agile was usually tolerated by the PMO, rarely understood or supported. And even when Agile become a recognised approach in the organisation the PMO will still act like it will never last.

To be honest with PMO managers, in recent times they were reduced to resource managers, hiring and firing PMs, or a reporting team that consolidates the useless weekly RAG reports in something more appealing to the executives. I had the unrealistic expectation to get support from PMO on solving the Risks and issues escalated. After all the PMO Manager had access to the layers above the project sponsor, the duty and the tools to hep with the escalation. The most support I had was a personal agreement from the PMO manager that I am right but I won't get any help.

I never considered Agile a methodology, but a collection of good practices and in relation to the concept of methodology an attribute rather than a methodology in itself.

It was reassuring to find out that even one of the co creators of Scrum never considered Scrum a methodology. 

"When Ken worked on the original paper on Scrum he was CEO of a Project Management Software company selling methodologies and that crept into the paper.

As we rolled Scrum out across the world it became clear that Scrum was a framework for inspecting and adapting to improve productivity, quality, and the work life of team members. It did not have the detailed practices in “methodologies” and was a framework for adopting additional practices that worked in various enviroments.

The Scrum Guide today calls it a framework. It is the minimal set of features that allow transparency and adaptability to drive performance that exceeds that of competitors" Jeff Sutherland

I see many questions on forums related to the "optimal" velocity for a Scrum Team. Most teams use a metric that is very relative: the Story Points, therefore a 'velocity' of 23 points for a team can be worst than a 15 points for another team because there is no way that 2 teams, even in the same organisation, can have the same understanding of what a the Story Point is.

I wonder why none of the Agile trainers, coaches and consultants didn't try to define what a Story Point is. Or maybe they tried and failed. It is, in my opinion, very interesting that the person credited to invent them apologised for inventing them..

In XP story points  made sense, because everything revolved around user stories but in Scrum where the backlog contains everything that needs to be done, including technical tasks, defect fixing etc. story points become a burden.

No wonder that the new frameworks are Lean-Agile, trying to combine the Agile happiness with the efficiency of Lean, because at the end of the day we have to pay the bills. 

recently I've seen quite a lot of post describing story points as a mandatory component of the Scrum framework. Besides the fact that the Scrum Guide doesn't mention them and in general any approach to sizing user stories I think that it is useful to highlight few points regarding Story Points :)

First, the person credited with inventing the Story Points, Ron Jeffries, clearly mentioned that they are an obfuscation of time, and although they may encompass complexity, size, risk etc at the end of the day they are a estimation of time need to complete that story. The big difference is that 3 SP doesn't mean 3 hr or days but a similar backlog item (user story in XP) that was defined by the team as a baseline for 3 SP.

Another interesting story about Story Points is that they were invented because of a manager/customer that needed a sense of control on the team's progress.

For those really interested in scope sizing I strongly recommend the Function Points method. It has many flaws but it has few excellent advantages over Story Points.

• It's a measure of size, not time.
• It' s consistent. It can be use to benchmark teams within the same organisation but also  between various organisations and even technologies
• There is a lot of very good quality historical data for planned project, wrongly called "waterfall". This data can be used to measure the benefits of Agile.
• Many metrics derived from Functon Point benchmarking can be applied to Agile: defects/FP, hrs/FP, Project/iteration size in FP etc

One of the areas of improvement in Agile is Metrics. Many teams keep talking about velocity, measured using a relative metric (SP). If the metric is relative the result will be very relative. 

Another issue with Story Points is that they can be very easily manipulated. Nothing stops splitting a 3 points story in 2 stories of 2 points or changing the original 3 in 5. Adding up at a Sprint level the difference can be +/- 1000%.

But there are also many advantages if story points are used wisely. That takes time and maturity.

• keep the estimation, no quotes because it is an estimation rather than a sizing, within the team. Using the story point to impress the PO, SM or any other manager (PO and SM are managers) is wrong and will always lead to gaming.
• use the estimation process as a knowledge sharing opportunity. If there are significant differences between team members then allow time for explanation
• Use the estimation process as a risk identification opportunity. Significant differences are a clear indication that one of the team members did't understood the item
• Use the results to measure estimation maturity and skills for the team, not for the team members. If the time needed to deliver the same item size is similar then you are doing good as a team
• Use the results to improve the process by reducing variability. If the estimation is good then the variance between sprints should be minimal
• Don't assign story points to defects, the user never asl\ked for defects. you better quantify the time spent on fixing defects in each sprint rather than trying to measure defects/SP. 

Most of Agile adoption surveys indicate Scrum as the most used Agile framework. Personally I believe that XP was more robust but perhaps it came before the time was right but I agree that Scrum, with his simplicity is a good framework and can be integrated easy and efficient with PMBoK combining agility with governance.

The guide has only 19 pages, including the cover, content and acknowledgements. It clearly defines 3 roles only: Developer, Product Owner and Scrum Master. It also defines the framework "founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known". 

What is known evolves with technology, the product development life cycle is dependent on technology. What worked in client server doesn't work anymore for  cloud and mobile applications.

I use Scrum for over 15 years, championed and implemented the framework in the "perfect storm": small and medium software development companies and I love it. I loved the fact that we learned doing it and we had the freedom to do whatever worked for us.

I see a lot of "Agile" certifications for roles that have nothing to do with Scrum. What is the value of a certification for an empirical framework? What does it certify? Is a 3 days course enough to learn Scrum? It took us, in a software development company, more than one year to understand it and become proficient. While I see value in training after few months of experimenting with Scrum, I believe that self study and knowledge sharing between the members of the Scrum Team is more benefic.

I don't believe that the "software Agile" was very successful because it was, from the beginning, "better" but because it came at the right time and because the environmentof the rapid penetration of devices using software in our lives.

Many Agile practices, like iterative and incremental and test driven development, were used for decades when the Manifesto was published. Some Agile frameworks XP, DSDM and even Scrum) were already used for years.

The big enablers were the Personal Computer, the cloud, mobile devices and last but not least the Object Oriented programming. Not only that software development become a widely spread occupation and done more and more outside the traditional "Computer Office" but with Pascal  and later c the way of thinking was different. In 80s computer time and technical performances (processing power, memory, storage) were the significant impediments. I remember the PDP 11 with 16 terminals and th3 256 MB hard drive. Then we had the first PC in mid 80s and what took one day to run on PDP took less than 2 hrs on the PC, we didn't need punch cards but we had to partition the 20 MB hard drive because it was too big.

Software is no longer bough as a product like in 2001, nowadays we consume software services (Facebook, tweeter, Uber, Amazon, eBay) or we rent it. However Agile values and principles transcended software development and practices developed in manufacturing are adapted to any projects with Agile becoming an option to be considered for any project,