I work in a large organization where there is only two agile islands that I'm aware of. Maybe couple dozen of developers out of 85 000 employee are actively experimenting agile framework. Not so long time ago I had a discussion with line manager who challenged the need for anything else but few managers in around 500 person division (brave opinion being one of those managers who should look for new role/position). This made me think about manager's role in an agile organization. It's a view I have given less thought in the past, while focusing on project organization and developer issues.
It's a fact that organization of this size has lots of managerial responsibilities. What if self-organizing teams would take up most of those responsibilities?
This brought me back to the basics making me believe in self-organizing developer team in the first place. That fact that current technology may very well be useless in two years, makes it essential for developer to be able to focus on taking these technologies by the neck every day - full time. This is what makes her capable of making those technical decisions which she is authorized to make by agile manager.
Isn't it the manager's new role to allow the talented developers to focus on learning new technologies and new product development?
Agile managers do this by facilitating, coaching, and trusting the team!
There exists more abstract agile frameworks on how organization could work in agile fashion to better synchronize with incremental development and further foster the flexibility. One of them is Cycles of Control framework(CoC, documented in licentiate thesis by Kristian Rautiainen). I believe that most of us are not ready to let traditional management levels go, but we need to close the gap using something like CoC.
3/30/2006
3/27/2006
Agile - State of the Practice
Agile Journal is a spinn-off of CM Crossroads (Configuration Management). In their first issue they published results from a agile survey. The survey was answered by the readers of CM Crossroad, so not specifically people interested or believing in agile development. Never the less, only 12% though that there is no benefit in applying these methods in their business. Still the most interesting point for me was that 32% answered that their organization is "first learning about Agile processes". This means that there is going to be huge leap in number of experience reports in near future. I'm still waiting for reports on long lasting affect of using agile methods. Most of the studies are on agile intervention level, where we can expect some bias from hype and enthusiasm. Some of the future research may even finaly close the gap between academic research and "agile research" (=story telling).
The survey had data from large organizations as well. As many of these were just learning agile methods, they are soon going to begin scaling the agile methods on enterprise level. Today in large organizations we usually have islands of agile knowledge, maybe just a agile team, but the positive experience fosters the information sharing.
The data from Agile Journal survey further showed that 17% had agile methods in use in two or more projects. This supports the fact that we are moving from extreme to mainstream. The study does not say anything about embedded system development, but I do not have any reason to doubt that our domain would not have been represented.
The survey had data from large organizations as well. As many of these were just learning agile methods, they are soon going to begin scaling the agile methods on enterprise level. Today in large organizations we usually have islands of agile knowledge, maybe just a agile team, but the positive experience fosters the information sharing.
The data from Agile Journal survey further showed that 17% had agile methods in use in two or more projects. This supports the fact that we are moving from extreme to mainstream. The study does not say anything about embedded system development, but I do not have any reason to doubt that our domain would not have been represented.
3/26/2006
Nothing to do? Try PICList and PICmicro webring.
I have worked quite a bit with different Microchip PIC microcontrollers over the past decade or so. The effort you can find in PICList and PICmicro webring still amazes me. It's been a while, but today I looked around. There are currently 168 sites in the ring. If you have nothing to do, start browsing, there just might be something valuable hidden under a rock somewhere...
Let me know if you find it.
Let me know if you find it.
3/23/2006
Geeky Programmer Meets the Japanese Warrior
Shu Ha Ri is a term used in Japanese martial arts describing the path a student needs to take in order to ultimately master these warrior skills.
OK, it's all clear how the warrior philosophy matches with geeky programmers, right?
Here are most common links: Shu Ha Ri was used by Kent Beck describing learning in Extreme Programming (XP) and also Alistair Cockburn used this to identify three levels of software method understanding. These level's were then expanded by Barry Boehm in his famous book about Balancing Agility and Discipline.
I have understood the grand Shu Ha Ri cycle controlling one's understanding of agile philosophy as something like:
OK, it's all clear how the warrior philosophy matches with geeky programmers, right?
Here are most common links: Shu Ha Ri was used by Kent Beck describing learning in Extreme Programming (XP) and also Alistair Cockburn used this to identify three levels of software method understanding. These level's were then expanded by Barry Boehm in his famous book about Balancing Agility and Discipline.
I have understood the grand Shu Ha Ri cycle controlling one's understanding of agile philosophy as something like:
- Shu - Believing that Agile Works: Learning the Fundamentals, Following Rules and Imitating
- Ha - Understanding Why it Works: Breaking the Rules, Mixing Methods for the Situation
- Ri - Knowing How to Get it Work: Breaking the Boundaries, Coaching Teams by Living the Moment
As this basically is the grand cycle I am experiencing, I still believe that this is an iterative process, and you need to return to Shu in order to achieve the true mastery. At that point you are able to see the original rules from the perspective of total freedom.
"The less effort, the faster and more powerfull you will be." - Bruce Lee
3/22/2006
It's going to be an interesting decade... (duh, again)
Yesterday a component distributor gave a summary presentation based on International Technology Roadmap for Semiconductors.
"The ITRS identifies the technological challenges and needs facing the
semiconductor industry over the next 15 years."
semiconductor industry over the next 15 years."
I also browsed through the actual paper, or only the Executive Summary (summary of 101 pgs). The key points that woke my interest:
- a single pitch reduction cycle every year (of course a part will not go through all rounds)
- 0.7 x price reduction for each pitch reduction cycle, resulting price half-time of two years
While these costs are only part of total microcontroller price (the paper forecasts very little reduction in packaging cost) we are living interesting times. The time will tell who are the winners in both the manufacturer and the new product development camps...
3/20/2006
The big Friday and the art of possible
Last week's Friday was the night. The 3rd Agile Finland seminar was held at the Museum of Contemporary Art Kiasma. The content of the seminar is reviewed by Jan Wikholm, so I am not going to redo it here.
This event showed again that agile movement is moving from extreme to mainstream, as the number of attendees was close to 200 persons from over 60 different companies. According Lasse Koskela (mc of the event) these companies range from enterprises to 2 person start-ups.
To the context of this weblog the night described nicely how agile is so much bigger of an issue than just Extreme Programming. Team building practices and understanding the complexity of novelty-work are just as important in any new product development, not just software development.
It is obvious that the hardware team of embedded system develepment project can not apply all the practices from Extreme Programming. Even the abstract Scrum framework may need some adaptation. This is where the "art of possible" plays a significant role. We need to dintinguish when we are just "being agile" and when we are practicing certain "Agile Development Method".
This event showed again that agile movement is moving from extreme to mainstream, as the number of attendees was close to 200 persons from over 60 different companies. According Lasse Koskela (mc of the event) these companies range from enterprises to 2 person start-ups.
To the context of this weblog the night described nicely how agile is so much bigger of an issue than just Extreme Programming. Team building practices and understanding the complexity of novelty-work are just as important in any new product development, not just software development.
It is obvious that the hardware team of embedded system develepment project can not apply all the practices from Extreme Programming. Even the abstract Scrum framework may need some adaptation. This is where the "art of possible" plays a significant role. We need to dintinguish when we are just "being agile" and when we are practicing certain "Agile Development Method".
3/16/2006
Subscribe to:
Posts (Atom)