You are currently browsing the category archive for the ‘Agile’ category.
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:
doing good engineering is not primarily making good decisions, it's seeking good feedback which lets you quickly discard bad decisions—
Kent Beck (@KentBeck) January 13, 2012
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,
A friend of mine, Managing Director of an european firm, called me a couple of years ago. He used to have a problem with his team: no one was taking care of responsibilities. The team was pretty focused but everyone was working his own “‘piece’ and putting the pieces together was not giving a good result.
So he called a senior manager and put him in charge of the product: no questions, he was responsible of the good and the bad of everything on that product.
Things were going better … till after some months he started suffering the same problem that his Managing Director used to have. And so he applied the same solution: took a couple of his top managers, splitted the product in two, and gave them full responsibility.
Things were going better … till after some more months they started suffering the problem the Senior Manager and the Managing Director used to have. And so the two Top managers applied the same strategy splitting the product and giving each of them some well defined responsibilities to some of their directs.
And so on through several layers of the organization.
My friend the Managing Director called my few weeks ago: he is happy the company is still open :) but he has the same problem. Everybody is now responsible … so nobody is responsible.
He need a new recipe: any suggestion?