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.
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.
Let me know if you find it.
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
semiconductor industry over the next 15 years."
- 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...
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".