Communication is not always about bureaucratic bullshit, policies, sharing info that someone joined or left the company or other pleasant things. Sometimes it’s about problems!
How do you communicate when something critical for you business is happening?
In this case involve everybody into a message if you really think it is serious. Everybody must understand the impact and see clients reactions. And it’s all about only adding additional recepients into the email.
I would treat it a success if at least one person makes a conclusion and tries to avoid similar problems in the future or it encourages someone additional to help. And i don’t care if most treat it as spam, distraction or waste. If i really think it’s important - i don’t care.
Listened to a very interesting talk by Alistair Cockburn - I Come to Bury Agile, Not to Praise It. It goes to my bookmarks. Here is the screenshot of the last slide that describes what was the talk about.
Guys from AccuRev created a nice list of Agile must know terms and expressions – Agile Glossary. I also decided to put it on my blog for my personal reference - http://agilemindstorm.com/agile-glossary/.
If you have any ideas or comments you can contact Kristine - email@example.com
In reality problems are most often outside capabilities and responsibilities of software development teams at all. As the result we are trying to solve wrong problems.
Are you sure you have the whole overview of a value chain? Don’t you think you should re-organize the way your work and build teams around value creation?
Find latest ideas related to network structures - http://agilemindstorm.com/2014/12/19/network-structure-why-part-0/ and also you need to track this guy - http://www.nielspflaeging.com/
But if you are still focusing on projects here are some ways for you to (not) remediate failed projects (aka dead horses):
- Buy a stronger whip.
- Change riders.
- Say things like, “This is the way we have always ridden this horse.”
- Appoint a committee to study the horse.
- Arrange to visit other sites to see how they ride dead horses.
- Increase the standards to ride dead horses.
- Appoint a tiger team to revive the dead horse.
- Create training to increase riding ability.
- Compare the state of dead horses in today’s environment.
- Change the requirements declaring that “This horse is not dead.”
- Hire contractors to ride the dead horse.
- Harness several dead horses together for increased speed.
- Declare that “No horse is too dead to beat.”
- Provide additional funding to increase the horse’s performance.
- Do a Cost Analysis study to see if contractors can ride it cheaper.
- Purchase a product to make dead horses run faster.
- Declare the horse is “better, faster and cheaper” dead.
- Form a quality circle to find uses for dead horses.
- Revisit the performance requirements for horses.
- Say this horse was procured with cost as an independent variable.
- Promote the dead horse to a supervisory position.
- Outsource the dead horse to a low-cost country
- Try switching to Agile….
- When that doesn’t work, Try switching to Lean
p.s. this great list is from Daniel Gullo in firstname.lastname@example.org group that i read today. I must share it 🙂