Velocity increase is evil

The practice of story points in combination with velocity and burn down charts can be a very powerful tool to make predictions for planning purposes. If teams know their velocity – based on actual experience in the first sprints, and have estimated story points for all requested items, team can make quite useful predictions about amount of time and therefore budget. This simple practice actually works in reality as described. It can be used for release planning and budgeting. The main difference with traditional way of planning is not relative estimation aspect, but continuous nature. Even story points practice that uses baseline of previously gathered experience will give imprecise calculation of work that still need to be clarified, and we therefore know so little about. It is important to regularly reestimate items on the product backlog, foremost for better understanding, and also improved predictions and better planning.

In fact, you could also measure team’s performance with this practice, as so often explained by Jeff Sutherland. “A good team should have velocity increase of about 10% every sprint.” If team’s velocity increases, it means that team has improved productivity, right!?

Measuring productivity based on velocity is illogical at best. It would be interesting to notice how one makes release planning and budgeting based on 10% velocity increase every sprint.

Using velocity to measure team’s productivity is wrong. Actually, extremely wrong. From all possible reasons for velocity increase, actual productivity increase is least likely. Let me give you the actual reasons for velocity increase:

Continue reading →

Discover own or use existing practices

We, Agile Coaches, preach experiments, inspect and adapt / short feedback cycles, and that early failure is good (although we don’t really mean “failure” in this context). In this way of working we discover new ways of delivering software, forever improving our profession.

On other hand, most of the daily challenges we encounter in software development are already solved by some previous team. In fact, these solutions are already documented in many great books and articles. So, why don’t we just read these patterns books and simply apply the solutions for any of our problems? Why experiment if somebody has already done it for us? I can assure you that your current problem and experimental solution has already been solved by somebody else in an enough similar context.

This dillema can be summarized by a frustrated developer who said to me once:

Why don’t you just tell us what to do, so we can get over this and just do it?!

Continue reading →

LeSS framework and architecting

LeSS framework is basically Scrum, only scaled-up. It is more an additional set of rules and a really good explanation on how to apply Scrum in a scaled situation and still remain effective, than a framework on its own. This is especially evident when compared to other scaling frameworks. LeSS can be used to work effectively on a single product with multiple teams, and even thousands of developers.

A particularly interesting part is the emphasis on technical excellence. It is one of the extremely important aspects often neglected in Agile introductions. Among things like clean code, TDD, continuous delivery, the framework also describes the way we should deal with Architecture & Design in a very refreshing manner. Instead of creating additional organisational structure, roles and artifacts, Craig and Bas give a number of tips.

Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design

This metaphor is intended as replacement for the building metaphor, which is usually used to describe what architecture means. The software systems are grown by incremental development, not built.

The rest is a large set of useful tips and direction of thinking when dealing with large scale Scrum. Here are few of these:

It is so important that every act of agile modeling and programming for the life of the system should be treated as an architectural act.

Standard whiteboards are possible but not usually sufficient–and in fact are often an impediment, because modeling is best done on vast open wall spaces without borders.

Encourage everyone to question and challenge all these assumptions [early architectural choices] and decisions, and to find ways to apply the lean thinking principle of decide as late as possible or defer commitment.

Technical leaders teach during code reviews.

Communities of practice (CoP) are an organizational mechanism to create virtual groups for related concerns.

Internal open source with teachers—for tools too

Don’t use stubs to delay integration

This should be captivating enough to make you visit the site.

Can we introduce real Agile mindset in a large traditional organisation?

The one million dollar question right!? A real answer is probably worth a couple of millions. 🙂

As often before, I’m “encouraged” by friends to explain better some of my statements. This time by Roy van Rijn. You should also visit his blog.

Let’s assume you are working in a multinational and a traditionally structured insurance company. A business request goes through many departments and it takes ages to get them in production. Business does not trust IT anymore and vice versa. This ends up in “sellling NO” or postponing behavior of IT people or creation of complex IT projects. CIO is a 40-year old guy who just bought a second hand Porsche 911 as a result of his midlife crisis. In other words, he is in the mood of trying out something completely different. He heard about Agile thing multiple times already. It seems that everyone is “doing it”, so he wants it too. Besides, he hears about these amazing stories where speed of delivery and quality have dramatically increased.

There is only this annoying small problem: his organization is a very traditional one, so introducing Scrum seems extremely disruptive or even impossible. As much as he is inspired by stories, changing so drastically seems very unwise. He invites several different “Agile” consultants / coaches and asks for advise. The one with most attractive approach will get the assignment and start with organisation-wide Agile transformation.

Continue reading →

Teams in the driving seat

Two weeks ago, InfoQ published our article about many experiences with Scrum at Port of Rotterdam. Several people contacted me afterwards with questions and one of them was an IT manager in a large organisation. He made a very short and interesting summary:

So, developers / teams are in the driving seat!

This characterisation is pretty good and can be used as a test for knowing how Agile your teams really are.

Very often, “being Agile” is confused with having teams following some set of practices “correctly”. That could be XP practices, Scrum practices (3 roles, 4 meetings), or something else.

“Teams in the driving seat” means that in a large organisation, information and artefacts are pulled instead of pushed. In a big enterprise, business has some need, which is usually pushed to IT management or product owner, translated by (business) analysts, pushed to Agile teams, which deliver a product in increments.

In case of really effective Agile teams, the need is much more pulled than pushed. The business still pushes the high level idea, with its very limited definition. After this, the initiative is taken over by teams. This switch may happen with a statement from the product owner:

My need is ….. Please enlighten me if this is sensible and what more you need from me so you can pick this up.

From this moment on, teams are in the driving seat and request or pull everything they need in order to deliver value. They are the ones actually deciding which information needs to be gathered, questions answered, artefacts delivered, process followed, and so on. They may request assistance from domain experts, BA’s or architects.

For large organisations with strict processes where first architects and business analysts are involved, direction actually set by IT people instead of business, different levels of management approval is needed, this is a major change in behaviour.

So, next time you hear someone telling you about their Agile teams, ask them who is actually driving the car and who is giving directions.

Fast changing vs. stable backbone & IT departments

IT departments in corporate world seem to have twofold management. Depending on affected systems, CIO’s will have completely different approaches to software development and operations. A traditional one for crucial or primary IT systems, and an Agile one for less relevant or fast changing business requests. Continue reading →

Technical debt metaphor is wrong

Martin Fowler has an explanation of technical debt metaphor as originally defined by Ward Cunningham. Many have misunderstood this metaphor. Interestingly, even Fowler gives an explanation, which fits the metaphor, but not explanation by Ward Cunningham. Cunningham even warns audience to not mistake this metaphor with intentionally creating unwanted design or a mess. Cunningham does not believe in “dirty way of doing things” as explained by Fowler, just to fix them later on. Fowler mentions deadlines as a major reason for quick and dirty. I believe that deadlines themselves are the actual problems, and therefore not a good reason.

Continue reading →

Continuous Architecting & DevOps

A lot is improved since Agile Manifesto. Still, one of the major complaints from non-Agile community is architecture and long term quality. The usual statement is that Agile people don’t care about architecture.

The price of short cycled incremental and iterative delivery of business value is paid with low long term quality and a mess in overall corporate IT landscape.

There is some truth in this, and there is a solution – already applied in corporate world- which does not only remove this argument against Agile methodologies, but delivers a better long term perspective than we ever had before.

Continue reading →

Toyota secrets from Mr. Yoshio Ishizaka

This morning I was privileged to participate in a small gathering in Hong Kong, where Mr. Yoshio Ishizaka told his story about Toyota and shared some of his personal experiences. Mr. Ishizaka has worked for Toyota since 1964 and has always focused on overseas business.

Continue reading →

Corporate world needs high quality Scrambled Eggs

Hong Kong is a culinary paradise. You can eat here almost anything, the quality is great, and the price is low. Major difference with European restaurants is the perception of service. In Europe we are accustomed to long evenings in restaurant with several courses, about half an hour between each course, a lots of wine, beer, or coffee at the end. Perception of service is about personnel being polite, knowledgeable, sociable. Also comfy chairs and tables, with enough space in between. Slow service is ok, even integral part of having relaxing evening, as long as it is not excessive. We don’t mind paying hefty price, but we also usually prefer eating at home because of it.

In Hong Kong, on other hand, perception of service is almost opposite. First and foremost, Hongkongers expect speed and food quality. Eating in restaurant saves time. Everything else seems secondary, as long as we are not talking about high-profile, more western-style type of restaurant.

An extreme example is Australia Dairy Company restaurant. It is a fast-paced, authentic place – more than 30 years old – where you can have very tasty scrambled eggs with toast! There seem to be a permanent row of people standing in front.

Continue reading →