I am preparing a presentation called Inconvenient Truths in IT Projects where I plan to discuss some aspects of software development that are prevalent and need to be discussed, but people don’t like to talk about in polite company.
Some of the topics I’m throwing around:
- No matter how hard you try, your estimates will be wrong.
- The more an organization proclaims they are “doing agile” the less likely they are using it in a way where they (or more likely their clients) will get true advantage from it.
- Your IT organization is trying to do too much.
- There is no such thing as “best practice”
- Complexity is not the best way to deal with complexity.
- The plan you created at the beginning of the project is wrong.
- A (potentially sizable) portion of scope creep is a result of learning
- The more complicated your process is, the less likely your teams will follow it.
- In the absence of an understandable, actionable strategy, people will make up their own
Do you like any of those?
Are there some that are missing?
Let me know in the comments.
Shane Hastie says
May 19, 2016 at 2:12 PMNo matter how much you want to believe you know “all” the requirements and that nothing will change, the reality is more than half of what you think you know is wrong
No matter how many usability gurus and other experts review your product and how thoroughly it is tested real world customers will find ways to use (abuse?) it that you never thought possible
Jmr says
May 19, 2016 at 6:22 PMAgile in IT without Lean in the business is destined to create chaos. IT cannot be “an agile bubble” forever without creating issues in the business.
Brian says
May 20, 2016 at 4:33 PMThere is no such thing as “best practice”
Yes they are but its a dynamic question – best practice needs to be defined for each and every situation – there are defined rules that must be followed in my world of Healthcare and relating to and adhering to Best Practices is most than essential or chosen its legally required.
KentMcDonald says
May 20, 2016 at 11:02 PMBrian,
Thanks for your comment.
“Best practice needs to be defined for each and every situation” is exactly why I say there is no such thing as best practice.
There are practices that are appropriate in specific situations. The key is understanding what situations they are appropriate in. Too many people get enamored with “best practices” that worked great in one situation and fail to realize that the situation they are trying to apply those best practices in are significantly different.
That’s not to say that ideas that work in one setting aren’t useful in a different, but only if people take the time to understand why a practice works in a given situation.
There is no such thing as best practice is also a warning against those selling silver bullets or one size fits all frameworks.
allan kelly (@allankellynet) says
May 21, 2016 at 3:33 AMYes, you are right.
I wrote something similar myself a couple of years back – with tongue in my cheek. Feel free to steal anything you want:
https://www.agileconnection.com/article/dear-customer-truth-about-it-projects
Or it you prefer a PDF
https://www.softwarestrategy.co.uk/wp-content/uploads/2014/01/DearCustomerSwStrat.pdf
Increasingly I believe it is the Project Fallacy that is at the root of much of this. the project model is a bad fit for software creation, as a result we spend much of our time trying to work around a flawed mental model. If we simply drop the start-stop idea and just think “work to do” we are much better off.
Tim Andersen says
May 22, 2016 at 10:18 AMI really like the title of “inconvenient truths…”, and I think it provokes discussion around ideas that could use more enough attention.
Knowledge transfer takes time. Even if a team is pair-programming and rotating regularly, a high-churn rate can diminish the overall productivity of the team, and if experienced people leave the team near the same time new people are joining the productivity is diminished even more. Similarly concerns apply if a project is being “handed off” to a different team.
Business decisions outside of your control can destroy everything your team has worked hard to establish. Developing software is expensive, and often times these “external forces” may have nothing to do with the performance of the team, but a change in management, an acquisition, market changes, or an executive budget decision may have a dramatic impact to the progress your team has made.
I’m curious about what other people do to anticipate or align decision makers so these impactful decisions aren’t made in ignorance.
Jon Harcey says
June 20, 2016 at 5:08 PMHere’s a new one.. Arbitrary deadlines result in incomplete solutions full of bugs while demoralizing the team.
We often get stuck with arbitrary deadlines from senior leadership or business partners who don’t know the complexity of the work. When IT gets held too tightly to these deadlines, the result is a team who is under pressure to deliver and takes shortcuts to deliver something, anything…full of bugs, and often not what the business really wanted.