Dec 30, 2008 / Friday's Digest #6 [Scrum, Crisis, Web 2.0]
0 comments- Is there an alternative to Scrum of Scrums? Will Read proposes Mesh network as a Scrum of Scrums replacement. Looks interesting as an information exchange flows in an organization.
- After The Crisis: A Parody of 15 Corporate Logos. Apple logo is very funny :)
- Jeff Atwood thinks that web application should not follow desktop application design. "A web app that apes the conventions of a desktop application is attempting to cross the uncanny valley of user interface design. This is a bad idea for all the same reasons; the tiny flaws and imperfections of the simulation will be grossly magnified for users."
- Herb Sutter found two fallacies in Jeff's post and think that this is a natural evolution. "Today, everyone writing rich Web 2.0 applications is doing their own thing, borrowing as best they can from Macs and Windows and others — but the results are all over the map, and will continue to be until there actually is such a thing as a UI standard for rich-GUI web applications."
I tend to agree with Herb. I don't feel bad when using web based app that looks familiar. And I definitely agree that in the future we will have several common frameworks for rich UI applications development with quite similar paradigms and interface concepts.
posted by Michael Dubakov @ 2:15 AM
Dec 22, 2008 / Observation: Lists in Web Applications
6 commentsI'm working on new lists in v.3.0 already and wondering how 37signals managed to create several web applications with no traditional lists. OK, there is one list that shows time records in Basecamp, but as far as I know there are no other such lists. All the other lists are very simple and well formatted. All 37signal's applications look simple, with fresh air and the first expression is very good.
Typical list in Basecamp:
The only traditional list I found in Basecamp:
Now I wonder why that happened. Maybe data volume in Basecamp is low? Maybe they are just super-smart folks (well, no doubt here)? Also I wonder whether it is possible to get rid of traditional lists in TargetProcess. Is it possible at all when people want to prioritize 300 user stories in the backlog (yes, we have such requests from customers!). Is it possible to get rid of usual lists when you receive dozens of support requests daily?
Labels: design, lists, usability, v3
posted by Michael Dubakov @ 6:09 AM
Dec 5, 2008 / Friday's Digest #5 [Charts, Scrum Criticism]
0 comments- New ASP.NET Charting Control. Looks good, but I prefer flash charts.
- Trashing Scrum or Reflecting Reality? David J. Anderson thinks that Scrum in it's current state is almost opposite to agile development "My observation from the outside is that the Scrum community reflects the antithesis of our agile values. It is run from the top. The message is strictly controlled. Dissent is not permitted. It resembles a cult of personality and appears to be the very definition of command'n'control in its execution".
- Is Scrum Failing Us? Alan Shalloway does not have such extreme feeling, but believe that there are many misunderstanding in Scrum "I want to mention some misunderstandings I have seen many people in the industry have and how we, as practitioners, can get beyond them. I have also included a few things many Scrum trainers believe that I don't agree with".
posted by Michael Dubakov @ 4:48 AM
Dec 2, 2008 / Edge of Chaos and Hyper Productive Software Development Teams
2 commentsIn the previous parts I've described basic properties of complex adaptive systems and it'sbeen shown that software development is a CAS. In my next few posts I am going to describe CAS properties in depth and apply them to software development. In this part we will look into the Edge of Chaos.
Many researchers tend to think that CAS may work efficiently at the edge of chaos. A system with a very high order can't solve complex creative tasks, as well as a pure chaotic system. It seems the system should balance between chaos and order to survive and adapt.
The "edge of chaos" term was emerged during self-reproductive cellular automata researches in 1990. It appeared that at a particular noise level the system can reproduce its state, while at a low noise levels states are random. This edge value was mathematically analyzed and it was shown that in such a state the system has a maximum of information.
The "Edge of Chaos" term spread and applied to complex adaptive systems. For example, we may suggest that evolution drives systems to the edge of chaos, and it is one of the reasons of life origin. Life is a very interesting and complex thing in itself. Most likely it could not appear neither in order state and in chaos state. Life exists if there is a stable base, but with possibilities of changes.
Edge of Chaos and Software Development
How can we apply the edge of chaos concept to software development? Obviously, edge of chaos is a state where the development team works with maximum efficiency. Complex processes and explicit rules impede creativity. The team becomes too ordered to think :). On the other hand, no processes and no rules lead to chaos. The development team can't complete anything useful, and that is something we call hack & fix process.
As a software development folks, we are particularly interested in two questions:
- How can we drive the team to the edge of chaos?
- How we will ensure that the team is at the edge of chaos?
The human who knows the answers to these questions most certainly will be rich and famous. However I am not sure whether you can find such a man.
It is obvious that edge of chaos = hyper productivity. This term often used in Scrum. However it is quite hard to define hyper productivity.
Well, currently we may discover hyper productive teams and identify their properties. But if we try to apply CAS to the edge of chaos, we may define the following properties that may lead a development team to hyper productivity:
- Feedback
- Information exchange
- Cooperation
- Self-organization
- High Adaptability
Agile software development processes have some of these properties explicitly, and some implicitly. For example, feedback, information exchange and adaptability are roots of agile development. Self-organization is something most are expecting to have in an agile process, but sometimes it is skipped. I think it is a huge fault if, for example, Scrum Master does not include self-organization into development process. All these properties are important and must have to build a highly efficient team. If you have 4 of them, but missed the last one, you do not have hyper productive team.
Clinton Keith identified four important conditions for hyper productive teams:
- Independence and a sense of ownership - The team needs to feel that they can contribute creatively and have some control over the game.
- Leadership - There needs to be one leader on the team who can communicate a vision between the team and the customers and keep the team focused.
- A core competency - Not everyone on the team needs to be an expert, but on the hyper-productive teams I have seen there have been at least one core expert. This isn’t a lead position defined by a role, but by actions. This person supports the vision with brilliance that the team can be confident in and rally around.
- Team collaboration - Teams grow into great teams organically. This is where facilitation can help a team transform itself.
Let's try to bind these conditions to CAS properties defined above. Independence is one of the self-organization pre-requisites. Leadership on my opinion is not a must, but likely is an effect of self-organization. The development team got a leader as a result of natural selection :) Core competency is a result of a feedback, learning and adaptation. The last condition obviously is an information exchange and cooperation.
We may easily define conditions, that block hyper productivity:
- No feedback. That is one of the reasons for waterfall process failure. In a waterfall process feedback is delayed and sometimes even does not exist. Team can't learn and adapt. Efficiency is low.
- Poor information exchange. Large teams, distributed teams, huge functional divisions, interpersonal problems - all that impedes information exchange.
- No cooperation. Political games inside a company or inside a development team, dumb corporate rules, wrong motivation schemes, communication problems due to personal likes and dislike - just some factors that make cooperation almost impossible.
- Impossibility of self-organization and weak adaptability. Complex corporate rules, hard hierarchy, command and control management, no autonomy make self-organization impossible.
We'll cover these problems in more details later. Even in such a brief overview it's getting clear what the main responsibilities of CTO, CIO, PM, Scrum Master, etc. should be. They should remove obstacles listed above (and more) that block a trip of the development team to the edge of chaos.
- Part 1. Agile Software Development and Complex Adaptive Systems: Intro
- Part 2. Software Development is Complex Adaptive System. No Doubt
- Part 3. Edge of Chaos and Hyper Productive Software Development Teams
- Part 4. Simple Rules, Complex Systems and Software Development
Labels: complex adaptive systems, edge of chaos, hyper productive, scrum
posted by Michael Dubakov @ 10:58 AM
