Path with cloudy destination

You can always get there from here

There are many quotes to the effect that perfection is a path and not a location (my wording in this case).  To me, this is the essence of agile vs waterfall (and, to a degree, SAFe).
Agile trusts that high performing teams, following processes that support continual re-evaluation, will produce higher quality deployable results with the same amount of resources.
All methodologies have processes (or ceremonies). Properly followed, they can all produce good results. Whether one methodology will produce better results than another is fairly moot, because it isn’t the methodology alone that influences the results. It is where the focus of the team is while following the methodology that makes the difference.
A team that is focusing on a date will almost always have to skip some steps to make that date.
A team this focused on the completed product is almost always  going to miss an import use case (very simple products excepted).
A team that is focused on absolute perfection of every task is going to miss business expectations.
A team that is focused on sticking to an iterative process and willing to course-correct their approach to improve the next iteration will always produce better deliverables.
Leadership is less about providing direction and more about communicating where the team should focus to be successful. The goal is to have a shared vision and foster the flow state that will support realizing some version of that vision at regular intervals.
Or, to use another similar quote, “This is the way”.
Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Software Project Failure

I’m on a roll with the LinkedIn rants today 🙂

Do software development efforts fail because: 1) the technical staff is not skilled enough for the work, 2) management has unrealistic expectations, 3) lack of reasonable resources to perform the effort. I would be interested to know your thoughts.

Someone once said that failure can only occur when time and resources are limiting factors. In the case of software, all of the above are true, though the most consistent cause I see is that the process of doing the following in order:
1) Set a completion date
2) Define the requirements
3) Design the software
4) Develop the software
5) Change the requirements
6) Wonder what went wrong

Agile is a good step in preventing failure from the above process except that even shops that use Agile often face that the end date is set before work begins and that unrealistic expectations are set at the same time.

Another ongoing issue is that management’s reaction to bad news about meeting functionality or a date is to throw more people on the project and demand more frequent meetings which pull the people most capable of solving the issue away from solving the issue. This trains developers to not communicate issues until the last minute, which accelerates this vicious cycle.

As Dennis Miller used to say “But that’s just my opinion. I could be wrong”

Facebooktwitterredditlinkedinmail
© Scott S. Nelson