The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.
Yes, he was quite a personable fellow :). On the other hand, I think it is okay to recognize that for a large portion of the world, the software crisis is a happy place, not a crisis at all. You get things done quickly with lower labor cost, you make $$$ even when it doesn't work. You sell a new version with new features that promises all things better, that also don't work as well, but at least it's by definition better than the previous version. It's like accepting the black plague as a welcome source for generating funds to support all kinds of medical activity.
So with interest I have been reading about feature teams (
http://www.infoq.com/resource/articles/scaling-lean-agile-feature-teams/en/resources/Larman%20Vodde%20Feature%20Teams%20-%20InfoQ.pdf ). And large parts of it just make sense. In the light of some recent developments, I love the fact that it recognizes social structures. A work place is not just about work. It's people spending a lot of time together performing tasks. It's a social structure in essence. It's high school revisited. Don't know what your high school was like, but there were probably small groups of students that hang out together. And you definitely had 'us' against 'them'. So what happens when you organize architects, developers, business analyst and testers all in different groups? You set the stage for scenes right out of high school. The teachers are the architects, the popular group are the business analyst, the outcasts are the developers and I guess the testers end up being the cool crowd. Setting up feature teams that are cross disciplinary just makes sense. Certainly since I strongly believe the following to be true about architecture:
- Architecture is done on a project by project bases. It's not something you just write and talk about, you practice it on each project you do.
- Architecture is not technology independent. Building a wooden bridge is architecturally different than building a concrete bridge. True, some high-level similarities exist, but architecture goes a lot deeper than just some high-level similarities.
- In a field that changes so quickly, architects have to practice what they preach. As an architect you have to know that your guidance is effective. Without practicing it yourself, you do not fully realize the impact your guidance has on the actual execution. And observations made during implementation should be translated back to architectural enhancements.
The piece on feature teams is good enough for me to buy the book "Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Products with Large-Scale Scrum" (Larman & Vodde, Addision-Wesley). I hope the rest of the book will be just as pleasant. Other goodies that definitely seem to apply:
Parkinson's law: As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization. This means that the architect group will compete for more architect resources, development group will compete for more developers, etc ... Feature groups are small groups that contain all these functions and that are directly tied to features of the final product. It naturally balances the mix without competition between each group for additional people.
Making things is about making people. So how much high quality training did you get this year? How much focus is there on your personal and professional development?
Project managers select people from a specialist resource pool and release them back when finished. This gives rise to projectgroups or feature projects, usually with matrix management. In such organizations one hears people called 'resources' as though they were machine parts and human or team dynamics had little importance on productivity or motivation. [...] In practice, resource pool and feature project management has disadvantages:
- lower productivity due to non-jelled project groups
- lower motivation and job satisfaction
- less learning
- lower productivity due to multitasking
- lower productivity and throughput due to increased handoff and delay waste
- lower productivity and increased handoff and delay due to physical dispersion
- lower productivity and higher cost due to more managers
[...] There us a very close relationship between the structure of a system and the structure of the organization which designed it. I even observe the same relationship between a business and it's IT department. Software development is a rather abstract business. And truly, people don't deal well with horribly abstract concepts. So as soon as we can touch a common similarity (or what is at least observed as a similarity) with a more concrete activity that is well-known to the business, there is a huge sigh of relieve. And after that sigh, it's just not a good idea to point out where the similarities end.
View the entire life cycle of the software. Don't chop the life cycle up in development as one part and maintenance as an other. You will notice that you start shifting work around between the two activities to fit your needs. If you run out of development resources, you shift it to maintenance (lower quality, incomplete features, etc.). If you are doing too much maintenance, you delay the work to the next development cycle. True question is what the value of the application is to the business during it's life cycle. What's the cost (including for instance missed savings due to none implemented features) and what's the gain.
No comments:
Post a Comment