Brief History of Agile Movement

In February this year agile movement completes 11 years of existence. I am sure you are either using some form of agile methodology or examining the possibility of using them. But, are you aware of how the agile movement happened? Did it happen by chance or was it inevitable? Do you know what influenced the agile manifesto? Who the authors are? What are their backgrounds and what do they do now? How was the name “Agile” selected?

The Influencers

It is clear from the notes published by Jon Kern that 4 methodologies had significant influence on the manifesto – they are:

  1. Scrum (Jeff Sutherland and Ken Schwaber – also Mike Beedle)
  2. DSDM (DSDM Consortium represented by Arie van Bennekum)
  3. ASD (Jim Highsmith)
  4. XP (Kent Beck, Ward Cunningham and Ron Jeffries – Martin Fowler)

Prior to the meet all these methodologies were classified as “Lightweight Methodologies”. The meet happened as a logical consequence of an earlier get together of XP proponents organized by Kent Beck. The push for the actual meet came from Bob Martin. Here are the milestones (1992-2003) that had significant impact on the movement. Also, I have tried to attach a face to every name – hope you find it interesting.

1992 – Crystal Methods

  Crystal was the starting point of the evolution of software development methodologies which ultimately resulted in what we know as agile movement. The honor of creating Crystal goes to Alistair Cockburn. The methodology was named “Crystal” only in 1997.

Crystal can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical. You can see the seeds of agile manifesto in Crystal because it focuses on – (1) Frequent delivery of usable code to users, (2) Reflective improvement and (3) Osmotic communication preferably by being co-located.

Here is a post by him on “Notes on the writing of the agile manifesto“.

He is a consulting fellow at Humans and Technology which he had founded. (See: His Biography page)

I could not locate him in LinkedIn.

1993 – Refactoring

  Refactoring was coined by Bill Opdyke in a paper titled “Creating Abstract Superclasses by Refactoring”.This is how Wikipedia describes code refactoring:

Code refactoring is “disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”, undertaken in order to improve some of the nonfunctional attributes of the software. 

He is now the Architecture Lead at JPMorgan Chase. (Soure: LinkedIn profile)

1994 – Dynamic Systems Development Method

DSDM, unlike all the other items listed in this post, was created by a Consortium. The consortium was an association of vendors and experts in the field of software engineering. The objective was to “jointly developing and promoting an independent RAD framework” by combining their best practice experiences.

There isn’t any individual who can be credited with the creation of DSDM but Jennifer Stapleton, as one of the founder member of DSDM consortium was instrumental in the initial compilation of thoughts.

She is now a management consultant in UK. (See: LinkedIn profile)

  Arie van Bennekum, one of the authors of the agile manifesto has been actively involved in DSDM and the DSDM Consortium since 1997.

DSDM focuses on the following 8 principles of (1) Focus on the business need, (2) Deliver on time, (3) Collaborate, (4) Never compromise quality, (5) Build incrementally from firm foundations, (6) Develop iteratively, (7) Communicate continuously and clearly and (9) Demonstrate control. Again, you can see the seeds of agile manifesto!

He is now a Senior Consultant, Programmanager, Project Manager, Facilitator, Trainer,  Coach, Mentor, Teacher etc. in Netherlands. (See: LinkedIn profile)

1995 – Scrum and Pair Development

Scrum

  SCRUM was jointly created by Jeff Sutherland and Ken Schwaberwho presented a paper describing it at OOPSLA ’95 in Austin, Texas.

Jeff Sutherland is the CEO at Scrum, Inc. (Source: LinkedIn profile).

Ken Schwaber is a founder of Scrum.org. (Source: LinkedIn profile).

Mike Beedle has been one of the very early adopter on Scrum and has introduced Scrum to many organizations since the mid-90’s.

As you know Scrum has practically been the de facto standard for agile.

He is now the Founder and CEO at Enterprise Scrum. (See: LinkedIn profile)

Pair Development

  Pair Development as a concept was simultaneously but independently written about by more than one person.

Jim Coplien published a paper titled “A Development Process Generative Pattern Language” which contained a pattern “Developing in Pairs”.

He is a Lean and Agile Software Development Coach in Denmark. (Source: LinkedIn profile)

  Larry Constantine talked about “Dynamic Duos” in his book “Constantine on Peopleware” published in the same year. This concept went on to become an integral part of Extreme Programming.

Though lot of research has been conducted to show the effectiveness of pair programming, the concept or philosophy does not really reflect in the Agile Manifesto.

He is now a Novelist, and University Professor in USA, (Source: LinkedIn profile)

1997 – Feature Driven Development

  Feature Driver Development was initially devised by Jeff De Luca.

The best practices of FDD are, (1) Domain Object Modeling, (2) Developing by Feature, (3) Individual Class (Code) Ownership, (4) Feature Teams, (5) Inspections, (6) Configuration Management, (7) Regular Builds and (8) Visibility of progress and results.

Interestingly, “Individual Class (Code) Ownership” goes against the concept joint code ownership which is considered a key practice today.

He is now the President at Nebulon. (Source: LinkedIn profile)

  However, the FDD process was explained to the world through the publication of the book “Java Modeling in Color with UML: Enterprise Components and Process” which he coauthored with Peter Coad.

He had built and sold TogetherSoft to Borland. Currently he is into many things other than Agile! (See: petercoad.com)

He has a LinkedIn page but it is empty with no connection!

  Jon Kern, one of the authors of the agile manifesto, had closely worked with both Jeff De Luca and Peter Coad and had helped shape the charter on FDD.

Here are his “Agile Manifesto Notes – Feb 2001, Snowbird, Utah“. These have been dug out and hosted by Jeff Sutherland.

He describer himself as Software Development Quarterback and is associated with multiple companies. (See: LinkedIn profile)

1999 – Many Things Happened

Adaptive Software Development

  Jim Highsmith formalized the Concept of Adaptive System Development and published a book with the same name.

The idea grew out of his work on Rapid Application Development methodologies.He proposed a three phase lifecycle of – (1) Speculation, (2) Collaboration and (3) Learning.

He has also written the history or the story behind the formulation of agile manifesto.He is now an Executive Consultant at ThoughtWorks. (See: LinkedIn profile)

The Pragmatic Programmer

  Andrew Hunt published the book The Pragmatic Programmer: From Journeyman to Master.

The book laid out characteristics of a pragmatic programmer as the one who is (1) Early adopter / fast adapter, (2) Inquisitive, (3) Critical thinker, (4) Realistic and (5) Jack-of-all-trades.

He describes himself as Pragmatic /ndy — speaker, author, publisher! (See: LinkedIn profile)

  The coauthor of the book was Dave Thomas.If you go through the detailed list of recommendation you will see its influence on the manifesto.

Here are his recollection of the what transpired in the meet in 2001 February – “Some Agile History“.

He describes himself as a Software Visionary! (See: LinkedIn profile)

Extreme Programming, User Stories, Release Planning and Continuous Integration

  While Kent Beck was working at Chrysler he developed the concept of Extreme Programming. He published the method in 1999 as a book – Extreme Programming Explained.As a part of Extreme Programming, he also introduced the concept of User Stories and Release Planning.

The methodology specifies best practices for planning, managing, designing, coding and testing.

He is at Facebook and calls himself a Programmer!! (See: LinkedIn profile)

  Apart from being a collaborator for the in XP, Ward Cunninghamis also as the creator of the Wiki.

Apart from being the Founder of Cunningham & Cunningham, he is also the CTO at CitizenGlobal. (See: LinkedIn profile)

  Ron Jeffrieswas also the collaborator and three of them together are considered as the founder of XP.

His biography page states that he developing software longer than most people have been alive. (See: Biographical Notes).

I could not locate him in LinkedIn.

  Though some people think that Martin Fowler introduced the term Continuous Integration in reality CI has also been coinedby Kent Beck.

Here is his recollection on the “Writing The Agile Manifesto“.

He calls himself an author and speaker and is working with Thoughtworks. (See: About Martin Fowler)

I could not locate him in LinkedIn.

2000 – Events leading up to the Manifesto

  Bob Martintook the initiative to get the ball rolling on organizing the historic meeting to be held on February 2001 at “The Lodge” at Snowbird ski resort in the Wasatch Mountains of Utah.

He is the Owner of Uncle Bob Consulting. (See: LinkedIn profile)

2001 – Agile Manifesto

2001 February + ‘The Lodge’ at Snowbird Ski Resort + 17 Thinkers = Agile Manifesto

Kent Beck, Mike Beedle, Arie van BennekumAlistair CockburnWard CunninghamMartin Fowler, James GrenningJim HighsmithAndrew HuntRon Jeffries, Jon KernBrian Marick, Bob MartinStephen MellorKen SchwaberJeff Sutherland, and Dave Thomas

2002 – More Agile Concepts

Test Driven Development

  For TDD the credit goes to Kent Beck. The concept of Test Driven Development also originated from XP test-first approach. It was given a shape later by Kent Beck through the book Test Driven Development: By Example.

Planning Poker

  The concept of Planning Poker was formulated by James Grenning.

Here is the original paper.

He is the Founder of Renaissance Software Consulting. (Source: LinkedIn Profile)

What about Brian Marick and Stephen Mellor?

  He is the Owner at Exampler Consulting and calls himself Software consultant, specializing in agile methods with a testing slant. (See: LinkedIn profile)
  He calls himself a “Freeter”, a Japanese word, derived from English, that means “free agent.” (Source: His home page)He resides in Zimbabwe and here is his LinkedIn profile.

2003 – Lean Software Development

 
Is Lean Software Developmentan extension to agile methodology? Should we look at it as something distinct from agile? Should it find a place in this post? I have included it for the primary reason that many agilists consider it to be one of the future directions of agile movement.Anyway; term was coined by Mary Poppendieck and Tom Poppendieckin 2003.

It is an adaptation of lean manufacturing principles and practices to the software development. There are seven principles – (1) Eliminate waste, (2) Amplify learning, (3) Decide as late as possible, (4) Deliver as fast as possible, (5) Empower the team, (6) Build integrity in and (7) See the whole. Amplify learning, deliver as fast as possible, empower the team etc. goes very well with agile principles.

I am not so sure about eliminate waste and see the whole.

Advertisements

Can Every Agile Team Self-Organize?

Statement (A): We know that some teams which have self-organized itself is much more productive compared to a team with similar set of members where the team organization has been prescribed from outside.

Statement (B): Self- organizing teams will always outperform an equivalent team with an imposed organization.

Is there a difference between the two statements or am I only playing with words?

Actually, the difference is enormous – and – of great practical significance.

To prove statement (A) we need to show examples of self-organizing team outperforming teams which are not self-organizing. Even examples of increase of team productivity through transition from traditional structure to self-organization mode will be sufficient.

On the other hand proving statement (B) is much more difficult – if not impossible.

Even one example of a traditional team being more productive or a fail attempt to improve productivity through self-organization will be sufficient to disprove the statement.

What is the difference between (A) and (B)?

Incidentally, if (B) is true then (A) has to be true – while the reverse is not correct.

Statement (A) can be restated as:

“…SOME self-organizing teams can be significantly more productive…”

And the statement (B) can be reworded as:

“…EVERY team can benefit from self-organization…”

Look at the emphasis on SOME and EVERY – that is the difference between (A) and (B). We can be reasonably sure that (A) is true, but what about (B)?

What happens if (B) is true?

If every team can benefit from self-organization than all you need to do if understand how to achieve it – what are the “do’s and don’ts”? Since most (all?) experts in agile community makes this assumption, there are enough advices available on how to achieve it.

Your task becomes much simpler. Not that it is easy to get a traditional team to self-organize it is much simpler compare to the alternative where you have to decide if the team will be capable of benefiting from self-organization.

What if (B) is not true?

When I say (B) is not true, what I mean is there CAN be teams which will not improve its performance by becoming self-organizing and the performance may even come down.

Let me just rephrase the above statement:

“…there are examples of team which has failed to self-organize or their performance has gone down after self-organization…”

I am sure you can find such examples and I don’t think it would be too difficult to do so.

It is possible to analyze these failures and point out what mistakes were made in the approach and give recommendation on how to avoid such pitfall. However, if the recommendation contains any one of the following then we may be indirectly accepting the fact that (B) is false.

Does it say that the Scrum Master was interfering too much with the working of the team? Does it say that the team needed more time to self-organize? Does it say that some member of the team was too dominating? Does it say that some of the key members of the team could not get along with each other? Does it say that some of the team members were too inexperienced?

In short, is there in suggestion that the team composition or the scrum master needs to be changed or they alter their attitude significantly?

This is as good as saying that this team – given its current composition – cannot self-organize.

In real life will you always have the luxury to select the right team?

  • What if you the team composition is given and cannot be changed?
  • What if the project time frame is too short to get people to change their attitude?
  • What if you cannot find more experienced people?
  • What if your key technical person has an attitude problem?
  • What if two key members of the team cannot get along with each other?

Such things happen in real life – so what should you do? Do you change the composition of the team and try to create a self-organizing team or do you resort to some amount of command and control?

Finally…

Depending on how you answer the previous question and how firm a believer are you on the effectiveness of self-organization – you can do one of the two things while starting a new project with a new team:

  1. No matter what, you assume that the team will self-organize and work towards that.
  2. You take a pragmatic view of the team composition and decide how much the team can self-organize and how much command & control is needed.

I am sure you would have guessed that I have a leaning towards the second option.

Agile Self-Organizing Teams and Role of a Leader

Agile team should self-organize. The Scrum Master can influence the process but not directly intervene.

We all know this.

Well, if you are not sure how this process works then you should read what Mike Cohn of Mountain Goat Software has to say:

However, do you really think that the leader should try to influence the team in a subtle manner? Is that what a leader is supposed to do?

Take the case of the “International Conference on Agile and Lean Software Methods” or …

Agile India 2012

Whichever way you look at it, the event was a grand success.

It had more than 700 participants and 120 speakers from 18 countries.

However, in my opinion, the biggest measure of success of any conference is to look at the closing session. Here is a 3 day conference ending on Sunday evening. You would expect to find the closing session to be half empty.

But no – in this conference the hall was full – as full as the opening session. That means participants found the conference interesting enough to stay till the end and attend the closing session.

Yes, it was an event where the organizing committee was self-organizing but how it happened makes an interesting story.

The Story behind Agile India 2012

105 days before the conference the organizer pulled out stating that the time frame was too ambitious. There were no sponsor for the event and hardly any registration.

Naresh, the conference chair, after consulting with the rest of the committee decided to go ahead – and – as you can all see, he did pull it off.

How did this happen?

This is what Venkat; the program co-chair had to say…

“…this would not have happened by any stretch of imagination without the hard work and thousands of hours that Naresh had spent…”

But, I think it is not just the hard work which is behind the success. The belief that it can be pulled off contributed as much.

Such belief is contagious and it rubs off from the leader to the rest of the team.

Such belief motivates the rest of the team to do the impossible.

 

5 Questions you need to ask before you outsource an Agile project

If you think that the following points are an oversimplification of a very complex subject of outsourcing agile project – you will be right and I agree with you.

However, I think these questions are a good starting point for your research before you actually go ahead and outsource an agile project.

1. Why do you want to do the project in an Agile mode?

Here are three possible reasons for wanting to do an outsourced project in agile way. Take your pick:

(A) You are already engaged in outsourcing and have established a good working relationship with the outsourced vendor. You have tried agile way of working internally and it has worked for you. You want to extend it to outsourced projects.

(B) You want to outsource a new project because you do not have internal bandwidth to either work on the requirement or on the development. You expect that outsourcing will help you overcome the bandwidth limitation and agile methodology will help you to evolve the requirements through multiple iterations.

(C) You do all your projects in an agile and to achieve immediate cost saving you plan to outsource some piece of work. So, it is natural for you to choose agile way of executing the project.

If you have chosen (A) then you then you have a good chance of success. The primary criteria for success of agile are trust and good communication and you seem to have both in place.

If you have chosen (C) then you may pull it off but you need to scale your expectation down on the immediate cost saving potential. It takes time, effort & energy to build relationship – initially that is going to be an overhead.

However, if you have chosen (B) then …

As it is, agile is communication intensive. When you bring in outsiders the communication load becomes more. So, if you are not in a position to devote time to understand what you need and create the stories, if you are not in a position to spend time to clarify doubts and answer questions as and when required, if you do not have time to meticulously review the deliverables of every iteration – your project will be doomed.

You should either understand agile well or you should understand outsourcing well before you try agile outsourcing.

2. Do you want to outsource just this project or are you looking for a partner?

This question is relevant only if you do not already have an outsourcing partner.

Agile without trust does not work.

Trust gets established between individuals and not between organizations. There is no substitute for an initial face to face interaction. At the start of the project key people from both sides should together at the same location and work together for a reasonable amount of time. One month would be ideal. If you want to optimize on cost, you should still have at least one week of working together.

Agile without a mechanism for smooth and effective communication does not work.

Setting up effective communication channel, be it dedicated communication link, be it video conferencing facility, be it necessary tooling infrastructure all require investment.

To establish these takes time … and effort … and energy. Doing it for just one project may not give you sufficient return on the investment that you make to get the whole think working.

Therefore, take a long term view and look for a partner who can help you with multiple projects.

3. What type of commercial model you should look at?

There are 3 alternatives – either one or a combination can work for you.

(A) You can have a Time & Material (T&M) contract where you agree on the rate for different people will different levels of experience and expertise and pay the vendor according to how much time they spend on your project. Though this is the simplest mechanism all the risks are with you and the vendor has no incentive to work more efficiently.

(B) The second alternative is to have a Fixed Price contract where you define the scope of the project in sufficient detail and agree to pay a fixed price for it. This runs counter to the basic philosophy of agile where you actively encourage requirements to evolve and change. Therefore, for fixed price to work you need to have a mechanism to compensate the vendor for changed requirement and rework, which you may do in a T&M basis. However, you need to keep in mind that what is a change and what is within scope can become a very controversial topic.

(C) The third commercial model can be based on some objective measure of the amount of work done. People have tried many different methods of sizing like using Story Point or Function Point. Each has its own advantages and disadvantages. The one I like is MK-II Function Point (this and this). It gives a good basis for calculating incremental effort. However, it does not cover effort required for rework, refactoring and impact of technological change.

I do not think there is one best method of structuring a commercial model. However, a good approach is to sign a Master Services Agreement (MSA) which specifies the overall terms and conditions including rate but does not get into specifics of a project. The scope of work can be outlined through a Statement of Work (SOW) which can include high level product backlog.

You may have to try out different model – combination of models – and see which one is best for you. Starting point would be to create a flexible MSA.

4. What payment term should you have?

Since Agile is iterative and there is emphasis on continuously delivery of “potentially shippable product”, you need to pay either at the end of each iteration or you need to pay at the end of a pre-agreed time period like at the end of the month.

If you decide to pay at the end of each iteration then you need to decide if you will enforce a mechanism of accepting the delivery of iteration. You need to decide what you will do if there are bugs or other forms of deficiencies found. You have 3 choices:

(A) You accept the fact that some amount of defects are inevitable and expect that those defects will be fixed in the next iteration and go ahead and make the payment anyway – this is not a very good idea.

(B) You set a threshold of defect and create a separate sprint to close those defects and accept the iteration only after all the defects are closed – this may upset your sprint planning.

(C) You do not your sprint plan but expect the vendor to correct the defects in addition to whatever is expected to completed in the sprint and release the payment only after all the defects are closed – this will put additional load on the team but will force them to deliver better quality product.

There is one more point which you need to keep in mind. One of the benefits of agile is to fail early rather than fail late.

So you need to have a clause in the contract of project termination midway if you realize that you are not going to get the business benefit originally envisaged.

5. Are you sure the vendor understands your definition of “done”?

One of the principles behind agile manifesto says “Working software is the primary measure of progress”.

However, in an enterprise context is that enough? Would the same set of people who have developed the code going to maintain it for years to come? Is there a requirement to follow any organizational coding standard and guidelines? Do you have any architectural standards that are practiced? Is the application usable? What about performance under real life load? Does it have to integrate with other pieces of software?

So, you need to have a clear definition of what is done. Here is an indicative list of points that your definition should take into account:

  • How you are going to test the delivery?
  • How much documentation is required?
  • Is there any architectural or design standard that needs to be followed?
  • Do you have a coding standard and code review guideline?
  • Do you need to have a Usability testing done?
  • What are the integration needs and how will you test it?
  • How are you going to measure performance under load?
  • Who is responsible for fixing issues while deploying in preproduction and production?

Not having a mutually agreed and a clearly written down definition of “Done” is one of the source of future potential dispute.

Finally…

There is no clear definition of what Agile Methodology means. So you need to thrash out any difference in understanding between you and the vendor. You may find it difficult to adhere to some of the points mentioned in the Agile Manifesto but do keep in mind the 3 important elements which makes Agile agile:

  1. Iterative development and regular delivery of working code
  2. Self-organizing team and emerging design
  3. Direct communication and immediate interaction

[Update: A version of this article is also published in Global Delivery Report]

Agile Practice and Work-Life Balance

Do you really believe that adopting agile practices will help you achieve work life balance?

One of the principles behind agile manifesto hints that it is possible:

“…Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely…”

However, the real world is different. We live in a world where we have an obsession with “Growth” … obsession with “Achieving more with less” … obsession with “Goal orientation” … obsession with “Stretch target”. To this you add the fast pace of change in everything around us – you will find that status quo is something which is very difficult to maintain.

Couple of days back I received a mail from Hema and here is an extract from that mail:

“…. I am a big believer in Agile and have been looking for companies that do real agile and have good work life balance. Do they exist or should women just move out of IT industry if they want work life balance if they care a lot about their kids? Are some roles better suited than others?…”

Many of you may echo this same sentiment … may ask the same questions. So, where do we look for an answer?

Assumptions contained in this statement

There are several assumptions inherent in that statement.

  • Adoption of true agile will lead to work-life balance
  • IT industry suffers more from work life imbalance than many other sectors
  • For a specific organization, work-life balance or imbalance will be uniform across
  • Work-life imbalance is role specific
  • This problem is specific for women

Are all these assumptions true?

Main reasons of work-life imbalance

In my opinion, the single reason which leads to work-life imbalance is when somebody (it may even be you) makes a commitment which cannot be fulfilled without putting in extra effort from your side – and you are not ready to face the consequence of not meeting the commitment.

The reason of why you cannot meet the commitment can be several. The commitment was made…

  1. …without an understanding of the complexity involved
  2. …in a competitive situation where the options was to either accept the deal with the given conditions or walk out of it
  3. …without considering the impact on other commitments already made
  4. …assuming a team composition, which for some reason cannot be realized – either people have left or you cannot find suitable people
  5. …from the top with the assumption that certain percentage improvement to status quo needs to be done
  6. … was derived from some higher level goal and handed down as given

Will adopting agile solve this problem? I really doubt it.

What can you do to avoid such situation?

The problem is not restricted to IT alone – neither is it limited to certain roles. Even if you are a school teacher you might find that you have been handed out with responsibilities which go much beyond teaching.

Agile practice, by itself, is unlikely to help you achieve work-life balance. Given today’s business environment it may even make it worse.

Here are few suggestions which may work. Though, I should warn you that our world has become complex enough and competitive enough to ensure that you need to run fast to stay at the same place.

  1. Learn to say “NO”. There is lot of stuff written on how to say no – just do Google it. Many people believe that Steve Jobs succeeded because he could say no – Steve Jobs: Get Rid of the Crappy Stuff.
  2. Learn to “Slow Down”. Did you know there is something called “Slow Movement”? There is even a Wikipedia page on slow movement.
  3. If you are still confused about what you want to do read this book – What Should I Do With My Life? Remember one gentleman called William Henry “Bill” Gates – he just walked out from the most successful company at that time which he had built from scratch.

Finally…

Here is an interesting report from McKinsey titled Changing companies’ minds about women or see this link. So, there is some hope for women. However, things are not changing very fast, so …

There are consequence to “saying no”, “slowing down” and “changing your career”.

Be clear that you understand those.

[Update (January 2012): Here are two interesting HBR articles]

How to Scale Agile?

Scaling agile is not simple. The complexity increases not in proportion to the size of the team but at the square of the size of the team. That means a 20 member team project will be 4 times as complex as a 10 member team.

To ensure that complexity does not turn into chaos it is inevitable that the pure agile way of working may have to be sacrificed – is it possible without violating agile manifesto? It is also inevitable that the agile practices will need to integrate into other practices of the enterprise.

To be able to scale agile we need to understand:

  • What the dimensions to this complexity?
  • How to split the problem and the team?
  • How to introduce processes and tools?
  • How to manage collaboration among distributed team members?
  • How to plan and manage workflow?

Dimensions of scaling and the need to integrate with other enterprise processes

Scaling Agile: An Executive Guide – Scott Ambler

To scale agile to an enterprise level, eight dimensions of complexity needs to be handled.

  1. Team size – from less than ten to hundreds
  2. Geographical distribution – from collocated to globally distributed
  3. Regulatory compliance – need for mandatory compliance
  4. Domain complexity – straightforward to complex and emerging
  5. Organizational distribution – from all in-house to multiple external parties
  6. Technical complexity – from homogeneous to heterogeneous including legacy
  7. Organizational complexity – from flexible to rigid
  8. Enterprise discipline – from no external constrain to need to adhere to enterprise standards

Different options of splitting the teams

Scaling agile teams – by features or by component? – David Draper

There are four options to split a large team into smaller sub-teams

  1. Component orientation: (Pro) Typically this is how developers align themselves. (Con) Need to split user-centric feature – focus shifts away from business value.
  2. Discipline: (Pro) This is how enterprises are already organized. (Con) Risk longer lead times with a “throw over the wall” attitude.
  3. Location: (Pro) Collocated teams tend to be more effective. (Con) Need to match feature set with specific team.
  4. Feature: (Pro) Aligns well with goal of delivering value. (Con) Integration issues may arise.

In practice a mix-and-match approach may be best where the split is done primarily based of feature and location.

Harmonizing the tool and process dimension with agile practices

Scaling Agile for Project Teams – Alan Bustamante & Rahul Sawhney

There is a need to harmonize three dimensions of people, process and tool. Here are some of the recommendations on how to achieve it.

  1. People issues are best tackled through structure, empathy, communication, and people-oriented policies.
  2. Addressing process challenges for scaling requires organizations to understand their process focus and validate that it is aligned with the organization’s vision, mission, and values.
  3. Focus on tools that support and facilitate the team and sub-team’s processes by eliminating or minimizing non-value added work.
  4. Configuring tools around a flawed process will still yield a flawed process. Fix the people and process issues first.

Making distributed teams effective through communities of practice

Scaling Agile to work with Distributed Teams – Mike Cohn

Total team size increases complexity. Distribution increases complexity. It becomes impossible for all team members to know each other let alone trust each other. One way to build the bridge is to set up communities of practice.

  • A group of likeminded or like skilled individuals which is self-organizing, organic and can span projects / location
  • All communities need not be officially sanctioned – they can completely informal to highly institutionalized
  • Creating proper environment for the communities is important

Managing the product backlog at multiple levels

Scaling Agile Processes: Five Levels of Planning – Hubert Smits

Agile planning activities for large-scale development efforts should rely on five levels:

  1. Product Visioning
  2. Product Roadmap
  3. Release Planning
  4. Iteration Planning
  5. Daily Planning

Product Vision is more like a desire of what the product will deliver once it is finished and would not talk about specific features. On the other hand Product Roadmap would talk about high level product backlog from which backlog for lower levels will be derived. It will communicate when releases are needed, what would be sufficient functionality and what business value would be delivered.

Like the two previous levels Release Planning is also for all the teams. Releases are defined by fixed date, theme, and planned feature set to which all teams must commit to. Typically, the product release would be once a quarter and the iteration cycle would be 2 to 4 weeks.

Managing workflow between multiple teams using Kanban

Large-Scale Agile – James Shore

Use Kanban for workflow not within a team but between teams.

  1. Treat each agile team as a work cell
  2. Use Kanban to manage cross-team workflow
  3. Create a Product Portfolio team which is collocated, cross-functional, intact team consisting of product managers, business experts, UX designers, architects etc.
  4. Partition the teams in such a way as to minimize the dependencies
  5. Monitor the system using lean techniques which is Visual control, Throughput and Value-stream mapping
  6. Sacrifice reuse in favor of throughput
  7. Keep communication flowing with Scrums of Scrums

Finally…

Since, to scale agile, we may have to deviate from the spirit of the original manifesto, the question is how much can we deviate and still call the resultant methodology agile? And, when does it become an iterative development methodology?

Incidentally, iterative development seems to be as successful as agile development. Have a look at this survey outcome.

Agile Projects are more Successful – Survey Result

Survey conducted by Scott Ambler has consistently (2008, 2010 & 2011) shown that Agile and Iterative Projects have been more successful.

Apart from the fact that Agile has been consistently been more successful compared to traditional approach, these survey result show two more interesting result – one of them is very surprising.

1) The gap between “Iterative + Agile” and “Traditional + Ad-hoc” has been increasing

It is not clear why there is a dip in the success rate of all types of project in 2010. But, leaving that aside, the gap has been consistently been increasing (2008=7%, 2010=13% and 2011=18%).

So, does it mean that people have really mastered the art of how to manage Agile and Iterative projects?

Or, does it been, people who are good at project management have abandoned Traditional approach and migrated to Agile or Iterative approach?

2) Iterative approach has consistently performed better than Agile

Though the difference is not very significant, all the 3 survey has indicated that iterative is slightly more successful compared to agile.

Does it imply that all the stuff in Agile Manifesto about “People over Process”, “Co-located Team”, “Face to Face communication”, “Cross functional team” etc. has very little to contribute to project success? When you scale Agile, you may need to violate some of them anyway.

Agile@Scale ≠ Agile@Manifesto

Word of Caution from Scott Ambler

He is quick to point out the known challenges with any survey.

  • You will only get responses from people willing to be surveyed
  • You risk getting responses from people with strong feelings about the topic
  • Very often questions capture opinions, not facts
  • The biases of the communities will be reflected in the results

This means (1) your survey sample may not represent the real world, and (2) your result may be based on opinion and not fact.

BUT, the question that we need to ask ourselves is…

…Has the time come for us to examine, which of the agile practices have a +ve correlation with project success and which are only rituals with no impact on the project success?