(A)
Be fast, risk failure and if needed quickly recover to succeed.
(B)
Be slow and successfully launch.
Obviously the option A does NOT apply to companies that are building planes, ships, cars, medical equipment and what not. However, it does apply to a lot of other IT organizations.
In option A, I am NOT talking about recklessly failing. I am talking about leading a team and trusting them without watching every single line of code and without introducing too many gates during the development of a project. As long as you have professionals on your team, you really need to use "let the baby out of the crib" methodology and allow them to fall as they are learning to walk as a team.
When I say "fail", I also don't mean failing foolishly breaking every rule in the architecture book; that's being foolish and not fast. I am talking about the culture where risking normal failures is NOT looked down upon. It is all about keeping the levels of this risk within normal boundaries and that requires a skill.
This is what "Be Agile" could mean. Let's call it "The Function of Agility":
void beAgile()
{
while(true)
{
developFast();
allowRiskOfSlightFailure();
quicklyCorrectIfNeeded();
succeed();
identifyWhatNeedsToImprove();
applyWhatNeedsToChangeIncrementally();
applyWhatNeedsToChangeIncrementally();
}
}
We don't need books and certifications. It just boils down to the above Function of Being Agile that we need to stick to; everything else is catering "Be Agile" approach to your company and it may mean that you implement what Scrum organizations put in place, or it may mean that you deviate from it in order to best achieve the goals in your work environment.
How do you gauge if you are on the right path?
It is simple. If the number of your failures is increasing over time and it is actually slowing you down, than you have to revisit the whole approach.
- almirsCorner.com -
#agile #fast #flexible #BeAgile #SoftwareEngineering #SoftwareDevelopment #teamwork
No comments:
Post a Comment