The Agile Enterprise

by
This blog will explore agility at the enterprise level, examining how agile principles can be implemented throughout the organization—and in departments other than IT.

About this Blog

RSS

Recent Posts

Story Points, solution or problem?

Certifications, training, self study - what's the Agile way?

Why was Agile so successful?

When did Agile start?

Lean, Six Sigma and Agile - One goal, one history

Story Points, solution or problem?

Categories: Metrics

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. 
Posted on: March 19, 2019 04:02 AM | Permalink | Comments (0)

Certifications, training, self study - what's the Agile way?

Categories: General

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.

Posted on: March 14, 2019 11:41 PM | Permalink | Comments (2)

Why was Agile so successful?

Categories: General

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,

Posted on: March 12, 2019 09:20 PM | Permalink | Comments (3)

When did Agile start?

Categories: History

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.

Posted on: March 12, 2019 08:53 PM | Permalink | Comments (7)

Lean, Six Sigma and Agile - One goal, one history

Categories: History

For many newcomers Agile, the new kid on the block, started in 2001 when the manifesto for agile software development was published. While it is true that the manifesto had a significant contribution, there is a history of 'out f the box' thinking that's is good to be know, to learn from the past mistakes and achieve the ultimate goal of the Agile Enterprise: responding fast to market changes in an efficient and effective manner. I believe that it is time that Lean and Six Sigma, merged in a a single discipline at the same time as the publication of the manifesto, joins Agile becoming the foundation of modern products and services delivery frameworks.

I believe that a combined history of Agile, Lean and Six Sigma is more than a lessons learned exercise, it is a recognition of the contribution of  previous generations  Instead of demonising everything that was done before 2001 we should retain the knowledge and learn from their mistakes but also from their achievements.

"We are like dwarfs sitting on the shoulders of giants. We see more, and things that are more distant, than they did, not because our sight is superior or because we are taller than they, but because they raise us up, and by their great stature add to ours."

Posted on: March 12, 2019 05:12 AM | Permalink | Comments (4)
ADVERTISEMENTS

The only people who find what they are looking for in life are the fault finders.

- Foster's Law

ADVERTISEMENT

Sponsors