Wednesday, November 7, 2012
Saturday, October 27, 2012
It is amazing. It does not only explain important aspects of the Product Owner role is an easy to understand way, but also visualizes central aspects of agile software development like fast feedback, velocity, and release forecast. And all of this in only 15 min!
The technique used reminds me of the famous "RSA Animate" 10 min science videos. One of the most remarkable maybe the one explaining Dan Pink's research about what motivates us. http://www.youtube.com/watch?v=u6XAPnuFjJc
Well done, Henrik!
Sunday, May 20, 2012
1) Choose internal change agents carefully
Positive mind and change orientated
Sense of urgency
Capacity for reflection
Work level experience in software development
Transition team covers different project roles and organizational units
Involve line management
Involve product management / business people
Involve process / Quality Management early
2) Be sponsor to the transition team
Give your vision, or agree explicitly to vision and mission of the transition team
Tell them what the constraints are
Be interested in plans and results.
Reed at least one good book yourself that does not look like a Scrum Bible, but something explaining what may work and why.
Do not expect to have NO impact on project time lines, this is just wishful thinking.
Give a reasonable budget based on estimates of the transition team
Do not tell them how to make the transition. Rather be able to discuss organizational changes on their request.
Let the team choose external consultants, but ask these people a couple of tough questions before you contract them.
3) Take care about trust in your organization
Do you, and do your middle managers trust your teams to get their job done? This is an essential part of any lean/agile transition.
If you are still not there, expect transparency to grow at the project team level, but you have to inspire trust from the management level. You need to start! You need to express trust to your teams and act accordingly yourself.
4) Do not combine a lean/agile transition with negative measures
Especially, do not try to reduce headcount. This is directly counterproductive to encouraging people to share their knowledge.
5) Foster a learning organization
Expect your organization to be on a learning journey for more than the transition lasts. The agile principles expect you to hire the best people, and give them the environment so they can be productive. In traditional hierarchical companies, often people need to learn to learn again. And often the environment consists of crappy old tools that make them slow. You may have tons of legacy code without automated tests. They will not magically disappear at the agile transition. The teams have to learn and improve a lot until they will really feel agile.
You will see improvements very soon, but this is not the end of your journey.
6) Look for opportunities to benchmark your transition with others
As executive you should use your connections with your colleagues from other companies for exchanging with them and creating opportunities for the transition teams and different project roles for comparing and exchanging experience so that you all learn more quickly.
Friday, May 18, 2012
At SEMCO they have proven it is possible to get rid of basically all kind of bureaucracy, if you start treating your employees as adults.
Written down process manuals are replaced by common sense, expanded knowledge, plus motivation to do your work in the best possible way to make your company succeed. Control and the needed to ask for permission for all kind of small things can be reduced to a minimum, from travel expenses to lunch invitations - if you just ask everybody to employ common sense, and have transparency on the numbers. Transparency is an important part of the SEMCO miracle. All employees and workers have full knowledge of revenue and expenses. This allows them to take meaningful decisions in factory committees, about what to change to get more efficient and make the customers happier. They are also fixing their own wages and hiring their managers. Hey, managers, getting scared now?
Of course such a company also needs leaders. But being leader there is not a question of status and privileges. They do not expect big personal offices and secretaries, but are just full of new ideas and ask nasty questions.
One important human organization principle that the company leaders adopted is keeping the units small: one plant or sub-company should not be bigger than 150 people. Pretty interesting, that Dave Snowdon gave the same number in his ALE2011 keynote asan evolution-built-in human constant for the size of a group a human will be able to identify with.
Democracy and open communication define the SEMCO identity rather than saying they agree in this or that business. There is a lot we can learn from them, if we are brave and fearless. Starting at a huge company may not be as easy, as there are politics around on many levels, and dragons.
What seems more promising to me is starting at a small or mid sized company, where the existing amount of process is not so overwhelming. First I would inspire lean and Agile principles. Software developers are often open to democratic principles, and shop floor workers often already know and apply a few lean methods nowadays. If we then start to engage teams of software and hardware developers, scientists, workers and sales people in how to build better products for the customers, our how to make design or production more efficient, they will sparkle with new ideas.
As people are learning together and get a broader view on the company's goals and the boundary conditions, they can make good improvement proposals. Then step by step some of them will learn to see the whole, at least to have a bigger interest in the company's business, and feel responsible for making their work more efficient.
Another book I have read recently is "Delivering Happiness" from Tony Hsieh, which will get its own blog post: learning how to really, really have company values and use them in daily life.
Wednesday, March 7, 2012
At the OOP 2012 conference in Munich, I presented together with a colleague from the higher management about our agile transition. Here you can find our slideset at Slideshare.
We have gone a long way from piloting to the real big transition, and now after the first big agile project has been successfully finished, there is still much to do in the sense of getting more efficient and having more fun...