Edge of Chaos | Agile Development Blog

Recently I’ve come across a post on harmfulness of analogies with martial arts. Indeed, there’s a handful of posts comparing software development, or agile adoption, or product development  with  martial arts  - Aikido, Karate, Judo etc.

If you make a direct analogy of software product development and mastering some martial art, it would not be exactly accurate. I guess  people revert to the analogies as they try to project their copies as romantic martial arts disciples into their usual lives as software developers, managers etc.  Perhaps, they’re making the image of their lives more mission-filled this way since there’s not too much space for showing primeval qualities of warrior in software development. But the need to exercise this attitude is still there, as it turns out.

We don’t have beasts to fight, bloody battles and mortal combats. This wrap-up for courage, strong will, persistence in achieving goals and readiness to fight has remained in the past largely. With no wrap-up, people forget that there’s lots of space to exercise these qualities in their usual life.

Let’s go back to analogies. Roger Federer is an unbeatable specimen of mastered elegant performance to me. Look at the way he plays. No waste. He knows, what to do, he knows when to do what. It’s a perfect flow,  the model for effective lean production with no waste and -  the model for perfect warrior  in our modern life. Elegant, no blood on his hands, but he fights, has pitfalls on the way,  stands up, recovers, marches on and wins gracefully.

But he’s just a guy in red T-Shirt. As many software developers

Another point is that it’s much harder to fight, win and achieve goals when there’s no immediate physical danger involved as in tennis.  Soo much room for elegant warriors, isn’t it ?

The point I’m trying to make is - let people compare their lives and their jobs to whatever they want. If it inspires and motivates them, makes them feel good about their lives and their work - and makes them feel like warriors, achievers, believers, fighters, winners.

P.S.  February 23 is a perfect day for such a blog post Wish you well, guys!

We’re all tied together by things we do. Projects we work on, conferences we go to as a whole team, even bugs we fix together, problems we solve together. Insights we share together.

Some people call it team spirit. Some people call it good collaboration. In any case, this is the light of live communication and talk between people.  My deepest belief after all is that no matter how sophisticated telecom stuff gets our days, there’s nothing more valuable - and ROI-generating as well - as the real talk.

I was perplexed the other day as I saw the phrase  - “we’re trying to maximize our face time with them” - this was said about some guys from an off-site location visiting the main office. My first thought was - so the rest of the time they work  is their a** time? As obviously software guys spend most of their time sitting on their derrier?? Though of course it’s worth a praise that after all they’re still trying to maximize the face time..

As hype is the statement that with globalization you could get the best software developers out of anywhere in the world, as eternal is the truth that to produce people need to REALLY collaborate. This goes for software, for any production.  So it’s not about picking up people as vegetables on the market - even if it’s a huge market. People are more than vegetables. They need live communication to feel alive, to collaborate and to be productive (for those who want to count figures, you can sit down now and compare the monetary value of pure programming skills  - with no communication skills at all).

I’m not saying that we should all go local in our quest for best products and profits. But what I really see is that people are squeezing their way to follow some of agile communication practices using telecom. As a proof, look at hot discussions at LinkedIn agile groups, and Jean Tabaka’s observations on the reasons of agile adoption failure.

Blasphemy to the religion of remote/distributed teams - but the picture is slowly starting to get clear for me:  it really takes good skills to balance the equilibrium of infrastructure and management to activate collaborative agile work in remote teams. Meaning 5 here, 7 there, 6 elsewhere - as one team.

Is it possible to trust without seeing each other? I doubt there’re teams who are absolutely OK with remote customers/product owners etc. I even suspect that waterfall can be the best solution for remote teams-customers that haven’t developed enough trust to each other. If anyone has real-life stories to prove that I’m wrong, speak up.

Fact: Complexity causes 50% of product returns

Fast and easy-to-use applications are quite rare. Simplicity and Performance are two major properties of any killer software product. We, as software developers, should pay attention to these properties as non-functional requirements, but in real life we often tend to implement more features, more functions, more settings, more, more, more… The race is hard to win with this strategy along the whole way.

I must confess we’ve done almost the same to TargetProcess. We went on with providing more and more features and options. Definitely we tried to keep the application simple and fast, but these goals were secondary. We’ve stopped. And changed.

Now we are focusing on better performance and usability. We think that TargetProcess is a quite feature-rich application that fulfills most needs in agile project management. It is time to stop and find answers to the questions: “Where do people get stuck with our software?”, “What is complex and how it can be simplified?”, “How to make TargetProcess enjoyable to use?”, “How to make TargetProcess the most performant software in our niche?”. The questions are hard to answer and address quickly, but we are looking for the answers.

Steven C. Seow wrote an excellent book about principles that should be taken into consideration for any “performant” application Designing and Engineering Time: The Psychology of Time Perception in Software. I read it and want to share some interesting observations.

Hick–Hyman Law describes the time it takes for a person to make a decision as a result of the possible choices he or she has. Simply speaking, less functions — simpler and faster choice. It leads to several conclusions what we should do as software developers:

• Minimize options. Obviously, if you have 50 elements on the screen, it takes time to choose which action is required. If you have 20, the UI is faster to work with.
• Keep it simple. Well, it is a general principle for all the facets of agile software development.
• Short system messages (10 words max). People don’t have time to read long messages. Delays kill usability.

Some concrete numbers from the book:

• Response time of typical action in the application should be about 2 seconds.
• If response time takes more than 5 seconds, it is required to show a progress indicator. User should know that system is working on the task.
• If system response time is more than 7 seconds, people tend to leave web site or switch to another task. It breaks interaction flow.

Noticeable Performance Improvement

If you are going to improve performance, it should be faster by more than 20%. Otherwise most people will not see the difference (it was shown in some researches that performance difference is noticeable in a range between 10% and 18%). For example, if you are improving search function with 10 seconds response time, it is required to make response time at least 8 seconds (or less).

Flow

Flow is very important for good user experience.

Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.

Our goal is to make the Flow possible. I think it is the hardest thing in software development.

When user opens an application and sees complex UI, it is frustrating for him. Application should match user experience and skills. Simple or Advantage modes, clean and simple UI (Hick–Hyman Law!), balanced options and functionality — this sounds familiar, but hard to develop.

We are receiving more and more requests to add individual velocity measurement in TargetProcess. People want to see this information and use for iterations planning. But is it required to measure individual velocity? What caveats such calculation has? It may be not clear initially, but there are some problems with individual velocity for sure.

What is an individual velocity? It is a measure of how much effort a person may complete in a defined time frame. In agile development time frame is an iteration. If Ted completed several tasks with 40 hrs of effort in total and Jerry completed tasks with 25 hrs effort only, we should say that Ted has better velocity in last iteration. Does it mean that Ted is a better/faster developer? Not at all. There are hundreds of reasons why Jerry completed less. He helped other developers with tasks and mentored them; he got serious headache during two days in a row and did almost zero progress; he had two birthday parties last week and his performance was no good next day after each party; one of his tasks was underestimated due to unexpected performance problem with third-party component. We can bring many more reasons on the table. Performance in last iteration says nothing.

OK, but what about average velocity? Surprisingly, Jerry’s average velocity is 54 hrs per iteration. Gosh! What happened with Jerry last two weeks? Will his average velocity help us to make correct iteration plan? If we sum up individual velocities all developers will it help us to create a better iteration plan? No, since we already have Iteration Velocity metric and it will be exactly the same. Why should we care about individual velocity in this case? To make better assignments for each person? But we still don’t know how much effort Jerry will complete next iteration. The good guess is from 25 hrs to 60 hrs. Is it helpful? Maybe, a bit. Is it worth the darkside of the individual velocity measurement? And sure there are some problems with it.

Individual velocity measurement has wrong focus on individual performance. The focus should be on team performance, individual performance is not important. If Jerry knows that his velocity is measuring, he maybe will not help other team members a lot. He will focus on his performance as an individual developer. The worst thing company can do is to bind bonuses to individual performance. This nips teams in the bud. The right solution is to measure team performance, but in agile development we already have team performance metric, it is a well-known iteration velocity - very good, very simple and very helpful metric that enough for iteration planning. Individual velocity will not bring additional benefits there.

Individual velocity measurement forces work assignment, while in agile teams it is all about work commitments. Team should do a commitment to complete as many user stories as they feel can be completed during next iteration. On iteration planning meeting Jerry may feel bad about his poor performance in last iteration (yes, developers know their performance without measurements) and will commit to 70 hrs work items in total and complete them all with courage. If you measure individual velocity you tend to assign stories based on numbers you have in hands. “Hey, Jerry, are you kidding? You did only 25 hrs last iteration, how are you going to do 70 hrs?” It is good if Jerry has courage to answer something like “Just believe me, I will do that” and project manager/Scrum master agrees and allows Jerry to make such commitment. But Jerry might think “oh, he doesn’t believe me… Well, let it be, I will take 50 hrs, it is close to my average velocity”. Individual velocity may demotivate people, and many managers having it in hands will use it incorrectly. It is very common to revert back to muscle memory of waterfall days and make assignments instead of commitments (especially when your project is in troubles).

I don’t see much value in individual velocity, but I do see many problems it may cause (or hide, or support).