You are currently browsing the category archive for the ‘Agile’ category.

Courtesy of gluemoon, Some Rights Reserved

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.

Use the same trick here: convince yourself you can do it 10 times faster, 10xFaster:
What can you make differently?
Can you cut a step in your process?
Can you simplify?
Can you use different people with different skills to it more quickly?
Are different roles beneficial?
Does it help if  you change the way in which people communicate?
Do you have to change software?
Are you really sure you have to do that extra manual step?

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.

PierG

For the fan of checklists here is a picture from the Red Bull Stratos mission: anything interesting in the background of this picture? :)

20121014-184610.jpg

The Italian Agile Day 2012 will take place in Milan on November, 24th at the University of Milan.

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

PierG

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.

from Total Cost of Ownership and the Return on Agility – All Things Distributed.

PierG

Lately I’ve blogged about internal IT projects that do fail and one of the main reasons: lack of Product Owner (Why big projects fail in corporate IT).
Today let me emphasize another major reason: often the team who’s in charge of a project … will leave (I’d say run away as fast as light) as soon as the project is complete. And usually ‘complete’ means ‘when we are exhausted of fighting with the supplier for bugs, change requests and new features’. And all this means that the project is not complete at all. And in any case we know it will evolve.
What is stimulating the project team, in such a context, to work effectively? Work for simplicity? Work to establish a system that will grow up or change in the future weeks / months / years? Are they measured in any way on these goals? Or are they measured on ‘close this fuxxing project quickly that we have already spent all the money they gave us’?
PierG

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.

PierG

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.

via George Dinwiddie’s blog » Post-Agile?.

What’s your thought?

PierG

By By R/DV/RS, Some Rights Reserved

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.

He bought a house. The house was already partially built when he bought it (quite common in Italy). As soon as he bought it, he had some choices to make like: where do you want the light switch in the kitchen?
Yes because in the contract the constructor left some flexibility in the form of multiple choices on some things:  in this way he can manage some of the changes the owner will need.
Now the problem is that Gianmarco wanted the light switch in a position and of a type that was not part of the options so … he had to pay an extra something (Change Request) and he did it ’cause it was his house, his dream.
As soon as he had time, so many things to do!!!, he went to the furniture maker who designed a great solution but … unfortunately they discovered the new position of the light switch was not good at all. Unfortunately the work to move the switch was already done and so some more money where need for another Change Request.
So two choices: have a ‘not such great solution’ or .. pay another something.
As it was his new house, Gianmarco decided to pay again.
That was a great period for Gianmarco as, few months before moving to the new house, his wife discovered to be pregnant! Great news!
The baby was born few weeks after they moved to the new house and quickly they discovered that this unexpected ‘event’ was not compatible with the brand new kitchen: there was no big table or proper position where to ‘sit’ him and have him under the watchful eye of his parents. So??? Another Change Request :)
Now, going back to my IT projects I have a question: why do we, as IT people, learn from the wrong examples?
PierG

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.

via Herding Cats: Planning.

I do love Glen Alleman and his blog. I often agree with him and in any case I find his posts interesting.

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,

PierG

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?

PierG

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 2,642 other followers

Connect with PieG

Certified Scrum Master

Map of Visitors

Anobii – my bookshelf

Here is (part) of my bookshelf and my wish list

Flickr Photos

Orange Moon - Full Lunar Eclipse

Mormom Row Panorama

OmniscientNarrators

More Photos

del.icio.us

Archives

Follow

Get every new post delivered to your Inbox.

Join 2,642 other followers

%d bloggers like this: