The Agile Enterprise

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,

For most people this looks like a very easy question: in 2001, when the Agile Manifesto was published. The first comment to this is that the "Agile Manifesto" is in fact the manifesto for Agile software development and while it is very important in the Agile history it is not the beginning.

Like many other discoveries "Agile" was originally a byproduct of military advantage. The first mention of an Agile approach is a study from the United States Department of Defense in late 50s aiming at finding ways to adapt military supplies to the specifics of war zones. It was the start of the Agile Manufacturing, and in my opinion manufacturing is still ahead in terms of agility. 

In the big scheme of things, like history, software development is a new topic. People "uncovered better ways" of doing it for millenia. Since we were hunters there were people that thought "out of the box" even when there was no such thing as a box :). The difference was the rate of change, thousands or even hundreds of years ago the society was pretty conservative and "new ways" were considered dangerous and sometimes crazy.There was no need for change as it is today.