Agility and Project Leadership

As I’ve been studying for the PMI-ACP, I’ve been reviewing the idea of the “Agile Triangle” which is an extension of the traditional “Iron Triangle” of traditional project management.  This is an idea that was originally conceived by Agile luminary, Jim Highsmith, where he states that “many agile teams are now caught in a dilemma. On one hand they are told to be agile, flexible, and adaptable, but on the other they are told to conform to pre-planned traditional Iron Triangle framework of scope, schedule, and cost. In essence they are being told ‘be flexible in a very small box.’ Agile teams are striving to meet one set of goals and managers and executives are measuring against another set”.
 

1. Value – for the customer in terms of a released product or deliverable.
2. Quality – continuous delivery of high quality and adaptive products.
3. Constraints - the traditional scope, schedule, and cost.

From this perspective, Agile teams should focus on releasing the project rather than getting constrained by the iron triangle.  The three end points of the iron triangle would collapse into one end point of the Agile triangle called constraints.  The other end points define the project’s goal of obtaining the value and quality of the deliverables that are of utmost importance to the stakeholders and that would require more attention.

Thus, according to Jim Highsmith, Agile teams should focus on the releasable product rather than getting constrained by the iron triangle. The three end points of the iron triangle collapse into one vertex of the Agile triangle called constraints. The other end points such as value and quality define the ultimate goals, since they are of utmost importance to the stakeholders and need more attention.

I do agree though with a blog by Rajeev Singh of “Agile Montage” that the end point of “value” could use more clarification, since as he states, “It is talking just about product/service value. It is restrictive to only customers and shareholders. How about Employee/Team Value? Or, even intermediary value focused on enhancing the core environment and sharpening the saws. For better software, we ought to think of empowerment, leadership and mentorship”.
 

He expands on the Agile triangle image by adding an intermediary and internal value to the “Value” end point:

As he states, “We just can't think at the project level anymore. We ought to start focusing on the whole organization. It is untenable to continue delivering external value without investing in internal value. The risk of not doing so is to put continuous improvement on the back burner.”

Just when I thought I had a complete grasp of the infamous “Iron Triangle” of project constraints, I run into the notion of the Agile triangle in my studies and learn something new yet again!

• Methods:
  • Scrum (obviously)
  • eXtreme Programming
  • Lean (as applied to software development mostly)
  • Kanban
  • Crystal
  • FDD
  • DSDM
  • RUP
• Practices:
  • Osmotic Communication (by Alistair Cockburn in his book “Agile Software Development – The Cooperative Game”)
  • Servant Leadership
  • Agile Risk Management (Risk burndown chart, audit backlog, and risk analysis)
  • Agile Planning and Estimation (user stories, planning poker, etc.)
  • Communications (standup meetings, customer interactions, etc.)
  • Agile Quality (definition of “done” and how you qualify this)
• Upcoming Practices:
  • Innovation Games
  • Control Limits
  • Agile EVM

LIke other bloggers here, I got a chance to download and read the excellent white paper titled "Distributed Agile Teams", which was based on an extensive survey and research done by Elizabeth Herrin on the Projects At Work site.  Its a timely report given the increased global nature of projects being launched by multinational companies around the world.  Though Agile is a strong advocate of having co-located teams, the reality is that you will most likely have development and testing teams in part of the world, while the product design and development in another with you as project manager coordinating it all from yet another location.

1. Flexibilty
2. Offshoring
3. Productivity
4. Timescales
5. Diversity
6. Visibility
7. Morale
8. Quality

I have written previously about the Microsoft based Scrum tools such as the MS Project 2010 and Visual Studio 2010 Scrum add-ins.  But there are also a plethora of open source alternatives that have been discussed on this site and one in particular I find interesting is Redmine.  It is a traditional PPM tool with the ability to track multiple projects and issues, act as a document repository, use Gantt and time tracking, etc. There has also been fertile development for plug-ins and of course, plug-ins for Scrum.  The tool is written with the Ruby programming language and built on top of the popular Ruby on Rails framework.

Being developed on the Ruby platform is what caught my attention I have to admit and one of the reasons is that Ruby and especially Ruby on Rails is famous for allowing rapid development and deployment and is touted as an especially suited tool for Agile development.  There’s even a popular book titled “Agile Web Development with Rails” that discusses this.

Ruby was conceived on February 24, 1993 by Yukihiro Matsumoto(Matz) who wished to create a new language that balanced functional programming with imperative programming. According to Matsumoto, he "wanted a scripting language that was more powerful than Perl, and more object-oriented than Python. That's why I decided to design my own language".  

Ruby is a dynamic, reflective, general purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features. It is based on Perl, Smalltalk, Eiffel, Ada, and Lisp.  The language also supports multiple programming paradigms, including functional, object oriented, imperative and reflective. It also has a dynamic type system and automatic memory management and is therefore similar in varying respects to Python, Perl, Lisp, and Dylan.

Most importantly, the language boasts impressive productivity gains for the developer that facilitate rapid development and Agile methods such as Test Driven Design (TDD), Behavior Driven Design (BDD), and continuous builds and deployment.  This is achieved by the language’s conciseness and readability.  Here’s an example comparing a Java class compared to a Ruby one:

Java:

Class Circle

private Coordinate center, float radius;

public void setCenter(Coordinate center) {

this.center = center;

}

public Coordinate getCenter() {

return center;

}

public void setRadius(float radius) {

this.radius = radius;

}

public Coordinate getRadius() {

return radius;

}

}

Ruby:

class Circle

attr_accessor :center, :radius
end

Some conclusions:

• Ruby code is at least 50% more concise than code written in other languages like Java, which means having to write less to get the same productivity.
• Having less code means less bugs to fix and less code to maintain (and refactor)
• It also means developers and testers can quickly prototype and test out features and functionality
• Ruby code is very readable following the "Principle of Least Surprise" (POLS) as well as encouraging the principle of "Don’t Repeat Yourself" (DRY) through dynamic programming
• With built in TDD and BDD, code quality increases
• Bottom line, using Ruby with Agile development reduces costs while simultaneously increasing productivity
   

As ScrumMasters and Project Managers, we like to focus on the work that leads to the end deliverables as well as the team and their skills and cohesiveness to get that work done.  But it is also important not to overlook the appropriate tools that can be made available to them and carefully picking ones that will increase their productivity as well as enhance quality, instead of tools that impede and frustrate them.  In software development, higher levels productivity languages like Ruby should receive special consideration.  

Read this interesting article on Scrum Alliance about individual team performance appraisals in Scrum teams and how they are antithetical to the process and spirit of Scrum.  As the author Nanda Vivek states:

The fundamental point is that if a Scrum team member is not able to contribute, then this points to a team problem. The Scrum spirit means that everyone jumps in to help; ideally, all team members work together on all of the stories. Different skill levels or types contribute to the best of their abilities. To create metrics for individuals, besides being inaccurate, would probably cause competition and division within the team. Individuals should work as a unit, be tracked as a unit, and succeed or fail as a unit...