You are currently browsing the category archive for the ‘Agile’ category.
Back in 2001, traditional management had the idea that if everything was documented, things would work out fine.
Three reasons to read this article:
- because in 2012 90% of management DO have the idea that full documentation means “it will work fine“
- because it’s an interesting article about agility and beyond (adding some lean startup concepts too)
- because most of the stuff that you read comes from Kent Beck and you should read everything from Kent. PERIOD.
Tell us what you think
I remember when I did the keynote at XP2007 and someone told me: “amazing how fast you go in your company, I’m happy my users are not asking me to go that fast” I remember I said “they don’t ask because they don’t know you can go that fast“.
I always think of that moment when I see teams with slow process, full of unnecessary steps that are usually in place for at least 3 reasons:
- historical reasons (= no one knows why AND no one asks why they are doing that way)
- “because dept. XYZ/important person ABC once told us to do that way” (= no one knows why AND no one asks why they are doing that way)
- for the illusion of control
When this happens, I suggest people to try something that I’ve learnt during my hypnosis training: time is not absolute. Time is not absolute in the sense that even if it were absolute, we just perceive it (as we do with reality in general). As we perceive it, we transform it through our senses. And as we transform it, it happens time can go faster or slower depending on … us.
As an example when you are on the dentist’s chair time is soooooooo slow while when you are on holidays … it’s unfortunately too fast :).
Now what if we apply this concept to your company, team, business, task, process? Take your ‘lead time': the time that is needed to go from the beginning to the end of the activity you want to speed up. Describe it putting everything inside: make a nice flowchart, Gantt chart, process map of what make you comfortable. Make it visual.
Now make the magic and say: what if I knew this stuff here can be done 10 times faster? Rule #1 stop saying “it is not possible” and start looking at all the components of your process as if you knew someone can go 10 times faster.
Our brain can be easily tricked: do you remember when your wife (or yourself) were pregnant? Do you remember how many pregnant girls you started noticing? Same stuff when you decide to buy a new car: it seems everyone in the world has that car all of a sudden.
This is called focus: your brain is so focused on this new important stuff that all of your energies go there and you start noticing stuff that you were not noticing before, your brain start automatically acting in a different way trying to satisfy your new needs.
Don’t let the context (rules, politics, …) limit your new behavior: you can di it 10 time faster!
Do it. For 30′. In team. Deeply. And then leave … because you know, in the moment you start this process, your brain starts to be focused in that direction and this is the best tool I know to start changing.
The program is ready: full of interesting lighting talks (10′), std talks (45′) and workshops (90′).
Do you want to meet me? See you there :) … and don’t forget to tweet with the official hash-tag #IAD12
Do you agree?
+ operational advantages such as setting up infrastructure in minutes rather than months, completing massive computational projects with a large number of resources quickly, and scaling architecture up and down to provide the needed IT resources only when you need them, deliver targeted IT solutions fast for individual business units – these deliver a “return on agility.” The return on agility delivers business value by allowing you adapt rapidly, while remaining focused on your core competencies rather than distracted by operating IT infrastructure.
But more importantly it allows the business to change and dramatically reduce time-to-market for products. It drives down the cost of experimentation and allows companies to explore many more product directions with minimal risk. In the current economic climate where capital is scarce, being able to develop new products rapidly without the need for major capital investments is crucial to the success of businesses.
Once Kent Beck wrote:
So if there is value in making good decisions, there is even more value in taking daily those decisions that improve our learning experience.
Let’s face it, working in an Agile fashion is hard. It requires paying attention to what you’re doing and the results of that. It requires thinking and making choices. It requires honoring the thoughts and feelings of those around you. None of this is easy stuff.
What’s your thought?
Every time I hear of a big IT projects, with a big RFP, with a big upfront multi-months/years analysis … I think of what happened to my friend Gianmarco some years ago.
Plans are mandatory. Make one, follow it.
Adapt the Plan to the emerging situation.
Without a Plan you’ll never know what DONE looks like.
Ignore that silly advice of respond to change over following the Plan
If you respond without a change in plans you’re lost and will not recognize DONE when it arrives.
What I don’t like about his new post is the mix between the concept of Plan (uppercase P :) ) and the definition of DONE.
It seems that something is DONE above all when you have done the last activity in your plan. And this might also be true but I don’t like the idea of coupling the concept of DONE with the execution of the plan.
DONE to me is about users using what you have produced, it’s not about someone having followed a plan. I prefer to stress the coupling between DONE & value actually being sucked from the product you have delivered. Or couple with the concept of learning: DONE it’s about giving the possibility to learn and explore.
The plan is important … and it’s not the goal, it’s not the DONE to me: that’s way, while there is value in following a plan, I value the response to change more if it helps in getting to DONE.
My 2€ cents,