Agility and Project Leadership

I thought it was interesting thatI thought it was interesting that an article in the very mainstream Huffington Post is about the application of Agile to one’s personal life.  It goes on about how to use “retrospectives” as a way to step back, stop and review where one is in life and plan forward just enough to get the highest priority items done.  This is sound advice which I think we all agree.

I thought it was interesting that an article in the very mainstream Huffington Post is about the application of Agile to one’s personal life.  It goes on about how to use “retrospectives” as a way to step back, stop and review where one is in life and plan forward just enough to get the highest priority items done.  This is sound advice which I think we all agree.

 

But one quote in particular caught my eye which is when the author Michele Serro states:

 

“Lean is a predominantly entrepreneur discipline; its aim is to build the right thing. Agile is predominantly a developer discipline; its aim is to build the thing right.”

 

In general, I think that’s a pretty good way of comparing the two methods as it puts it in the perspective of a kind of Yin-Yang relationship and accounts for why Lean has become a quite popular and growing addition to the Agile suite of methods.  Think of terms like value stream, Kaisen, Kanban, etc. in the Agile vocabulary and this is truly the case.

 

In the final analysis, what this nice little quote is indicative of is that fact that we need to see and think more about how the various Agile processes and methods complement and integrate with each other, which is a bit more Eastern approach, rather than to view these as separate and distinct concepts applicable to a specific domain, which is a more Western perspective.

 

What do you think?  Do you mainly view the complementary aspects of Agile or the distinctness of them?  Which is better?

What do you think?  Do you mainly view the complementary aspects of Agile or the distinctness of them?  Which is better? an article in the very mainstream Huffington Post is about the application of Agile to one’s personal life.  It goes on about how to use “retrospectives” as a way to step back, stop and review where one is in life and plan forward just enough to get the highest priority items done.  This is sound advice which I think we all agree.

 

But one quote in particular caught my eye which is when the author Michele Serro states:

 

“Lean is a predominantly entrepreneur discipline; its aim is to build the right thing. Agile is predominantly a developer discipline; its aim is to build the thing right.”

 

In general, I think that’s a pretty good way of comparing the two methods as it puts it in the perspective of a kind of Yin-Yang relationship and accounts for why Lean has become a quite popular and growing addition to the Agile suite of methods.  Think of terms like value stream, Kaisen, Kanban, etc. in the Agile vocabulary and this is truly the case.

 

In the final analysis, what this nice little quote is indicative of is that fact that we need to see and think more about how the various Agile processes and methods complement and integrate with each other, which is a bit more Eastern approach, rather than to view these as separate and distinct concepts applicable to a specific domain, which is a more Western perspective.

 

What do you think?  Do you mainly view the complementary aspects of Agile or the distinctness of them?  Which is better?

Yes, we all know andYes, we all know and love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far?  It could be that the promotion of the flexibility cause both teams, stakeholders and customers to expect and demand too much flexibility which causes too many and difficult to manage changes  leading to project delays, quality problems and teams that had difficulty delivering value.  

Yes, we all know and love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far?  It could be that the promotion of the flexibility of the method is what causes both teams, stakeholders and customers to expect and demand too much flexibility.  This causes too many and difficult to manage changes leading to project delays, quality problems and teams that had difficulty delivering value.  

 

Is Agile too flexible for its own good?

 

In this article by Lajos Moczar in CIO magazine, he thinks the whole method is flawed:

 

Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.

 

I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here…

 

In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes. Every change has a cost, but agile does not account for this. The result?  People often change really big things late in the game using the rationale that since it's an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.

 

From my perspective, it isn’t so much that Agile is too flexible, but rather that people are too flexible in their use of Agile.  I think the real flaw is to blame the method for being flawed due to misuse, rather than one’s misuse as being the flaw that causes flawed results.  For example, it’s like blaming a hammer for being a flawed tool because you tried to use it to hammer a screw into a wall, rather than admitting that your flawed use of the hammer is what cause screw to damage the wall.

 

I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself.  What do you think?

I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself.  What do you think? love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far?  It could be that the promotion of the flexibility cause both teams, stakeholders and customers to expect and demand too much flexibility which causes too many and difficult to manage changes  leading to project delays, quality problems and teams that had difficulty delivering value.  

 

Is Agile too flexible for its own good?

 

In this article by Lajos Moczar in CIO magazine, he thinks the whole method is flawed:

 

Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.

 

I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here…

 

In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes. Every change has a cost, but agile does not account for this. The result?  People often change really big things late in the game using the rationale that since it's an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.

 

From my perspective, it isn’t so much that Agile is too flexible, but rather that people are too flexible in their use of Agile.  I think the real flaw is to blame the method for being flawed due to misuse, rather than one’s misuse as being the flaw that causes flawed results.  For example, it’s like blaming a hammer for being a flawed tool because you tried to use it to hammer a screw into a wall, rather than admitting that your flawed use of the hammer is what cause screw to damage the wall.

 

I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself.  What do you think?

There’s no doubt that Scrum has becomeThere’s no doubt that Scrum has become the most popular of Agile methods for software development and other projects, but if we step back a moment, we have to sometimes realize that it is a lightweight “framework” for managing projects, whereas Agile as outlined in the Agile Manifesto is a set of “values”.

There’s no doubt that Scrum has become the most popular of Agile methods for software development and other projects, but if we step back a moment, we have to sometimes realize that it is only a lightweight “framework” for managing projects, whereas Agile as outlined in the Agile Manifesto is a set of “values”.  It is your responsibility to align the use of Scrum with the Agile values.

 

With this being the case, I’m getting lots of anecdotal evidence that Scrum is becoming within the industry the very evil it was to overcome.  Namely, a rigid command and control  process that enforces a mechanistic adherence to iterations, ceremonies and artifacts.  Examples would be a rigid conformance of spring planning models that must follow specific ceremonies, maintaining who controls and manages the backlog, and how Sprints should be deployed (or rudely “pushed” out).

 

This rigid robot like mindset is quite antithetical to the values and sprit of Agile, but with the commercial success of a method like Scrum and it’s widespread adoption both within its software development roots and outside it, there seems to be a growing trend of a more dogmatic, stifling and stale version of Scrum that is permeating the industry.

 

Like I mentioned, I don’t have lots of data either quantitative or qualitative to back this up, but it is a sentiment that seems to be growing and shared amongst those who for the most part feel that Scrum was pushed down on them because someone heard it was a popular Agile method.

 

Am I right or wrong?  I’d like to know what you think!

Am I right or wrong?  I’d like to know what you think! the most popular of Agile methods for software development and other projects, but if we step back a moment, we have to sometimes realize that it is a lightweight “framework” for managing projects, whereas Agile as outlined in the Agile Manifesto is a set of “values”.

 

With this being the case, I’m getting lots of anecdotal evidence that Scrum is becoming within the industry the very evil it was to overcome.  Namely, a rigid command and control  process that enforces a mechanistic adherence to iterations, ceremonies and artifacts.  Examples would be a rigid conformance of spring planning models that must follow specific ceremonies, maintaining who controls and manages the backlog, and how Sprints should be deployed (or rudely “pushed” out).

 

This rigid robot like mindset is quite antithetical to the values and sprit of Agile, but with the commercial success of a method like Scrum and it’s widespread adoption both within its software development roots and outside it, there seems to be a growing trend of a more dogmatic, stifling and stale Scrum that is permeating the industry.

 

Like I mentioned, I don’t have lots of data either quantitative or qualitative to back this up, but it is a sentiment that seems to be growing and shared amongst those who for the most part feel that Scrum was pushed down on them because someone heard it was a popular Agile method.

 

Am I right or wrong?  I’d like to know what you think!

A job hunt is a big and complex project. You need to decide what to do and when. Who do you interview with? Is it time to iterate on your resume? Do you have enough references? Are you networking “right”? Add the fact that your emotional well-being is affected by your search, and—well, it’s a recipe for low self esteem.

 

One way to manage this complex project is to use a project management approach that fits the problem. The best way I know is to use personal kanban. Personal kanban allows you to take everything out of your head, get it down on sticky notes so you have the transparency, and then see it move across the board to get to done. You have a way to limit the work in progress and a way to corral those call-backs with the Pen.

 

As she discusses, its about using the tool to manage that complexity by prioritizing those WIPs that are the most efficient AND effective for your job search.  And as the graphic from her example shows, no need for fancy dashboards, just write this down on your job search notebook.

 

 

For those job seekers out there, what tools from your PM toolkit either from Agile or traditional are you using to land your next dream job?

A job hunt is a big and complex project. You need to decide what to do and when. Who do you interview with? Is it time to iterate on your resume? Do you have enough references? Are you networking “right”? Add the fact that your emotional well-being is affected by your search, and—well, it’s a recipe for low self esteem.

 

One way to manage this complex project is to use a project management approach that fits the problem. The best way I know is to use personal kanban. Personal kanban allows you to take everything out of your head, get it down on sticky notes so you have the transparency, and then see it move across the board to get to done. You have a way to limit the work in progress and a way to corral those call-backs with the Pen.

A job hunt is a big and complex project. You need to decide what to do and when. Who do you interview with? Is it time to iterate on your resume? Do you have enough references? Are you networking “right”? Add the fact that your emotional well-being is affected by your search, and—well, it’s a recipe for low self esteem.

 

One way to manage this complex project is to use a project management approach that fits the problem. The best way I know is to use personal kanban. Personal kanban allows you to take everything out of your head, get it down on sticky notes so you have the transparency, and then see it move across the board to get to done. You have a way to limit the work in progress and a way to corral those call-backs with the Pen.