On Pareto Principle

It has been many years since as a part of the Online IT team at a media company, I was part of the team effort in self-training in agile including prioritization techniques. During our mock up scoping exercise, a concept came up that 80% of value come out of 20% of requirements. We discussed where 80-20 concept applies in software development some further and came up with quite a long list of how this principle applies: 20% percent of project deliver 80% of value , or 20% of the team members deliver 80% of work. The latter has to be validated though – I hope this is Pareto exception J

Then, a few month later, I took an advanced project management class and learned about the Pareto chart and distribution types and where and how it applies.

Vilfredo Federico Damaso Pareto (http://en.wikipedia.org/wiki/Vilfredo_Pareto ) (15 July 1848 – 19 August 1923), born Wilfried Fritz Pareto, was an Italian engineer, sociologist, economist, and philosopher. He made several important contributions to economics, particularly in the study of income distribution and in the analysis of individuals' choices. He was the first to discover that income follows a Pareto distribution, which is a power law probability distribution. The pareto principle was named after him and built on observations of his such as that 80% of the land in Italy was owned by 20% of the population.

The Pareto principle, also known as 80-20 rule, helps define efficiencies for multiple systems – in software development and far beyond. Not that is universally applies – but thinking about this rule helps re-evaluate approach to project scope, resource allocation, and personal productivity. How? Just one example. In agile prioritization while prioritizing features and placing those on sprint backlog, we can try to identify those 20% that will actually bring 80% of value and acknowledge that while product backlog is never exhausted by deifnition, we are constantly delivering the need 80% to the business.

Hmmm. How universally is the distribution actually applicable? We are not talking income in Italia – can we apply this curve to software development? One of my colleagues actually tried to apply bell curve distribution to performance appraisals at an HR seminar on the topic. I personally advise against applying Pareto principle to bonus distribution though J

The 80-20 rule is applicable to multiple other situations and environment. Please provide your suggestions – and the one who provides the best input will receive a Pareto award. The winner will be selected by a poll – so total transparency and fairness is guaranteed.

And in conclusion, what is obvious to me is that 20% of the readers of this blog post will provide 80% of the valuable comments and Pareto samples. Are you in?

P.S. This  posting is my first attempt of taking a different look at familiar concepts. I’ll see whether it is of an interest to you. If it is, I am ready to continue with a new look at Deming and Plan-Do-Check-Act cycle. Or maybe you have your own views or suggestions for good candidates for the “Known Unknowns” category. Or does “Unfamiliar Familiars” sound better?

On Leadership

What is the modern perception of a leader? How is it different from what it was ten years ago? How it is applicable to our everyday work reality? No matter whether you a in a managerial title or not, did you ask yourself this type of questions?

Not that I have an answer. But I think it’s important to ask those questions once in a while. Each of us is a leader – in one capacity or another – but not always we realize that, or acknowledge the responsibility that comes with leading others.

I know what was a common perception of a leader in a workplace ten years ago. Someone knowledgeable who has the answers and provides clear and detailed directions to the team. Good communicator. Fair. More like a mentor and advisor.

How is team motivated in this case? It’s easy. As Agile Manifesto states, we are all good citizens. Team members in general want to please their managers and to be considered good contributors by  their peers. It’s in human nature. Things may get different but that’s for a different topic. So level 1 in team quality – compliance – is easy to achieve.

What this approach lacks? Buy-in from the team. Thus – level 2 in team quality: creativity. Level 3: Sense of ownership. Growth opportunity – in literal sense. Ability to grow up as a professional and start making decisions on your own. In the case of a decision-making manager, this is a leader by title and a governance tool but not someone who serves the team in terms of team-building and providing the members with the opportunities they need to succeed.

Is this getting different in a modern world? It is and it is not. People are not necessarily changing easily. In technology, however, we are more prone to change – because of the nature of our industry. We won’t survive professionally without constant learning – and this means the change by default. That’s why agile concept – self-organizing and self-building (self-maturing, self-governing, etc. etc.) teams – emerged in IT.

This does not mean that we lack managers who give orders – and teams are following those (remember, we are all good citizens by nature), however, we have the new breed coming – those who see management function in serving their teams – making them more efficient by satisfying their needs – shifting decision making and ownership to their members and empowering them with ability to think creatively and take  ownership. And the process has started – and I can see it well with the emerging USES agile team – and not just IT members of the team. And it’s a good picture.

I really like the concept of leadership as a service. And this concept is not a new one. Mahatma Gandhi said: “The best way to find yourself is to lose yourself in the service of others.” This concept perfectly applies to project management, any other area of management, or leadersip in general. It is so important to be a servant, not a manager who gives instructions but leader as a team member who builds trust and promotes respect. This is the key to team’s success.

I listened to a webinar on leadership and project management. The presenter was talking on  leadersip and success as it relates to project management. She said: number one driver for project success – guess what? Business case with proper ROI calculated? Resources? Careful planning? Fixed scope? No! Trust between team members. If this is not achieved, this results in slower delivery, lower quality, knowledge trasfer gaps, high maintenance costs. And number one recipe for failure? The environment where people are afraid to admit their mistakes, where collaboration is not promoted, where individual success is above team’s success.

And this is fundamental. Project success is not about technologies and processes. It is about people. So if we fail as a team, it means that we are not ready to take ownership, to makes decisions, to put our success as a team over each member’s personal contribution.

And what is leader’s role on the team? Serve the team by building it based on trust, respect, open communication. That’s why a new term comes into play: leadership as a service. I think this term reflects the nature of modern leadership very well, and a manager is a service provider to the team in the same sense as SAAS vendor provides a service to its customer.

What do you think?

How My Team Decomposed Agile

Below is my submission to NY SPIN Process Nightmare Session in April 2012. This submission was selected, and I had a chance to present to the audience of software professionals. It was a great experience both having a chance to present and to listed to my fellow presenters about their experience. My favorite question from the audience was "If you did it all over again, what would you do differently"? Guess what I answered?

Anyway, below is the submission.

An “Agile Hammer”

(How my team decomposed agile)

Summary. Have you ever heard of a hammer analogy when people talk about scrum adoption? Imagine you need to put a nail down and decide to use a hammer, but you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency. This is what my story is about: how my team adopted agile by decomposing it, and as we were progressing with our implementation, we realized the value of all the missing ceremonies and ended up with an efficient “agile hammer”.        

How did it happen?

In 2005, when Agile adoption rates according to Forrester research were about 15%, I was a project manager on a team of 13 (6 developers, 3QA, 2 BAs, dev manager, and I) responsible for development and support of an enterprise level proprietary application. We were a waterfall shop and I quite enjoyed my role of a PM – my 10-page Gantt charts gave me a sense of accomplishment and I felt I was in control as long as my MS Project Plan was updated on a daily basis. The only downsize was normally towards the end of the project when I was able to accurately assess progress and it would become obvious that after 6 months of hard work and one week into QA testing we are completely off track and something needs to be urgently done. Then, I would alert my business stakeholders, risk and issue logs would start growing exponentially, and for another 3 months my team would lose any sleep trying to catch up. 4 QA cycles later, after descoping or phasing out nearly 50% of functionality, we would deliver working software, then struggle to fix post-production defects for another two or three weeks, and after celebrating the fact that the nightmare of that release is behind, we would start new projects slowly, giving a chance to developers to relax a little bit during requirements gathering. Despite the team working crazy hours, the business was never appreciative citing long time to market, low quality, and lack of visibility into the project progress.

And then one day dev manager called a meeting and said: We are going Agile. I thought he meant: We are going crazy – because at that time we were into the “meet-the deadline-or-die” phase of the project when the business informed us that because of a competitive product which was just release, the work we were doing for 6+ months was useless and we had to start requirements gathering cycle all over again. So I asked what he meant by Agile, and he said that this is a new framework which will help us adapt to the changing business needs and we would be able to produce working software within two weeks. We all laughed. Our application was a multi-tier multi-technology enterprise level platform with a distributed team in 3 countries working on it – how was that possible? Quite possible, he said, and here are the rules: you meet every day for 15 minutes, have a business stakeholder dedicated to the team and available every day, you stop doing hourly estimations and assign abstract point to your requirements, which are not requirements any more – they are called stories, and when you are done, you invite the stakeholders and show them the work. We said that it is insane to move from 9 and 12-month projects to two weeks, and besides, how do we know if it works? Retros, he said, it’s like lessons learned, we will inspect and adapt, and this way we will continuously improve our practices.

We decided to give it a try. The first few months were a nightmare. Our daily “sit down” meetings were one hour long, we were constantly stepping on each other toes. Our product owner was telling the team to switch to a different project mid-sprint. Acceptance criteria were not available. Product backlog was not prioritized. We decided not even to try estimation – this was too complex to grasp. We were not meeting our commitments. Our retros were more about complaining how painful this experience is and how we miss waterfall with uneven load and unhappy business stakeholders. We started moving towards agile more: implemented story point estimation, started to stand during daily meetings which miraculously became shorter, started parking discussions and answering only three standard questions, our retro became focused with action items which we were tracking. The business gave us a stellar feedback, and after sprint 5, we were stunned when someone on the team noticed that we stopped having post-production defects. However, we still had our mini-waterfall within each sprint: requirements gathering, development, QA, and UAT. We even split the team into two, so that their cycle overlap and eliminate productivity loss. We thought we were doing as well as it is possible until a during sprint 12, someone from QA said that she wanted to do some development and was successfully trained. One sprint later, we need additional QA resources and one of the developers volunteered to help. We merged back into one cross-functional team and abandoned mini-waterfall.  At that point, we thought we cannot become any more productive, but our productivity tripled, and other business units decided to try agile because our stakeholders were as satisfied as never before. It was not perfect and commitments were still occasionally missed, but we as a team – no longer divided into business and technology – were confident of our ability as a team to deliver high quality work while growing professionally and enjoying what we were doing.

This team-level transformation took us over a year, and now looking back, I realize that we made a natural move from agile piecemeal to a standard scrum implementation. While being able to realize some benefits right away, we were step by step implementing standard practices – stand up meetings, story point estimation, retrospectives – and moving towards Agile. Each step made us more successful, but only when we connected all the dots, we were able to see exponential growth of productivity. This reminds me of an analogy I came across in one of the blogs. Imagine you need to put a nail down. Take a hammer. Let’s say you do not see the value or just don’t know how to use the hammer. So you decide to decompose it into two parts. Now you can use a handle or the metal part to put the nail down, and either part is more effective than a bare fist. But only when you use the hammer as a whole the way it’s intended to be used, you will be able to achieve true efficiency.

Since this first experience, I worked as a scrum master on many teams, and finally moved to another employer and became part of team that is responsible for company-wide transition to agile. In my role of an agile coach, the first thing that I tell our teams is: Agile requires discipline, do not try to pick and choose until you master it well. Only then, you will be able to determine what sprint duration, what estimation technique, and team composition is optimal for your team. Follow Agile framework that you chose step-by-step, otherwise you will learn the value of Agile as a whole the way my first team did, through painful trial and error, through a “hammer” approach.